林兆星 case:
  K05 SQL 召回(无 actual periodontic) ✓
  chain.status=entered(1 年前 fulfilled "牙周" 预约) — 客观真实
  矛盾:旧逻辑 plan-aggregate 只对 discovered chain 改 target → K05 entered target=false
        → UI 不 ★ → 客服看不到该召回

修(plan-aggregate.assemble):
  ① target 计算覆盖所有 status(不限 discovered)
  ② 用 (code + tooth) 联合 key 匹配,不再仅 code:
     reason 有 tooth → chain.code 同 + tooth overlap 才 ★
     reason 无 tooth(全口诊断 K05) → 任何 code 同的 chain ★
  → K08 林兆星 4 条 chain,只 17 那条 ★(SQL 召回 K08@17),其他 K08 不 ★ ✓

前端(chain-viz.chainStatusVisual):
  target=true 时优先返回 "★ 潜在新链",压过 chain.status(entered/ongoing)
  原因:SQL 是真理 — 该召回的就显示 ★,即使历史预约让 chain composer 算 entered
       chain.status 仍展示真实状态(S2 节点显示历史预约),但顶部 badge 优先 ★

验证(林兆星):
  3 个 SQL reasons:K08@17 / K05@全口 / K03@46;47;48
  对应 3 个 chain ★:
    ★ 牙体修复·46;47;48 (K03)
    ★ 牙周治疗·全口 (K05,entered+target=true)
    ★ 种植修复·17 (K08)
  非 ★ chain:K08 其他牙位(已做种植 SQL 排除)+ 外科 closed

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