裁决开发规划 Q-6(原判「8 标签 ← K 码一对多，无解」)。原建议是给 8 个业务标签
另定一张标签级窗口表并明写「这是新口径」；**否掉**，因为真正的解法是换一层聚合：

  逐条 gap 用自己 K 码的窗口判档 → 再取最热

一对多自动消解(extraction 里 K01 那条按 K01 判、K03 那条按 K03 判)，
不需要任何新常量，DiagnosisTreatmentMap 是真的被复用了 ——
教条 T6「不新增口径」与 canonical-codes「不允许任一处再硬编码窗口」都不用破例。
原判「无解」源于默认了聚合必须发生在天数层。

同时修掉旧聚合的**反单调**:先 Math.max(daysSince) 再判档，会让「上周刚查出的龋齿」
因为身上还有一颗两年前的旧龋而被判成冷 —— 多一条未满足需求反而更冷。

存边界时刻而非天数/档位(解冻)：
  daysSince 在 VOLATILE_DATA_KEYS 里被 stripVolatile 剔掉 → 时间流逝永不触发重算
  → 温度档永久冻结在画像算出来那一刻。改存 hotUntil/warmUntil(= 锚点 + 窗口)，
  读时跟 now 比。二者由「事实日期 + 静态配置」推出，不是易变键。
  同一套路本仓已用过两次(visitRecencyRange / applyLiveDays)，这是第三次。

「不知道」不等于「冷」：老画像无边界 → classifyTemperature 返回 null 而非 cold，
否则老数据会静默塞满冷格子，主管看到一个假分布还看不出哪里假(T14)。

⭐ 顺带抓出并修掉一个**静默归零**缺陷(教条 §4.38)：
assignment-proposal 按 `pe.id = fp.persona_id AND pe.superseded_at IS NULL` 关联画像，
而 plan 的 persona_id 不随画像升版本更新 → 重算一次后条件恒为假、筛选变 0 条。
实测:全量重算后池子里只剩 97/2,724 指向活版本，「潜在种植」按 persona_id 得 0 条、
按 patient_id 得 376 条(列表页一直是后者)。已改为按 patient_id + 源码形态护栏。

实测量级(本地 5,825 患者，召回池 3,880 个「患者×标签」格位)：
翻档 1.31%(43 变热 / 8 变冷，其中 6 条是压线、2 条是 K06 被当成 K05 的误判改对)。
⚠️ 拿未过 gap 闸的原始诊断事实去量会得到 40-70% 的夸张差值，那是错的人群。

917 tests passing；本地全量 persona 重算 success=3020 refreshed=2143 unchanged=662 failed=0。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>