上一版(1293108a)只在**新建** reason 时补标签,漏了 `plan-engine` 的**就地刷新**路径
(plan-engine.service.ts:569):signals/evidence 语义变了但不升版本时,
它直接 `planReason.update({ evidence: { factIds } })` 改写证据。

🔴 那条路上 `potential_labels` 既不是 NULL(收尾的 backfillMissing 会跳过它)、
  又已经对不上新证据 ⇒ **初选矩阵按旧标签把人算进错的格子**,
  要到夜间全量重算才自愈,中间一整天不报错。

⇒ 同事务里把这些 reason 的 `potential_labels` 置回 NULL(=「没算过」),
  本轮收尾的 `backfillMissing()` 用同一份 SQL 填上。
  ⛔ 不在这里用 TS 顺手算一个:规则表是产品配置,第二份实现迟早和矩阵那份漂开。

⚠️ 走 raw:Prisma 的**标量数组字段不能用类型化 API 置 null**(tsc 会拦);
  而改用 `[]` 会让「没算过」和「算过是空」分不开 —— 那正是这一列设成可空的理由。
⚠️ 第一版 raw 写成 `IN (a,b)::uuid[]` —— **tsc 全绿但 SQL 是错的**
  (cast 套在了布尔结果上,PG 报 `cannot cast type boolean to uuid[]`)。
  这类错类型检查天生看不见,只能真连库跑一次。已改 `= ANY(ARRAY[...]::uuid[])` 并实测。

顺带:单患者重算路径(recomputeForPatient)也补上 backfillMissing ——
  ⛔ 不补的话这位患者在矩阵里**当场消失**,直到夜间重算才回来。
  平时代价接近零:`potential_labels IS NULL` 上有部分索引。

测试：
  · 替身补 `tx.$executeRaw`,并给 engine() 传标签刷新器替身
  · 新断言「证据被就地改写 ⇒ 必须同时标记重算」——
    ⚠️ 做过变异校验(把期望改成 99 立刻变红),确认这条断言真的在跑,不是假绿

验证：tsc 通过;jest 86 套 1342 例全过;矩阵基准 24 格仍与基线逐字相同;
  eslint 无新增错误(plan.service 里 3 条 no-empty-object-type 是既有的)。