前一刀(跳转前必答)让 plan_executions 有数了,这一刀把它接进批次报表。

1) plan_executions 加 assignment_id
   理由与 plan_event_logs 那次一字不差:followup_plans.assignment_id 会被下一次
   分配覆盖,时间窗是启发式不是键。
   ⚠️ 落这一列的判据是 assignment_expires_at != null(「非空 ⟺ 有一次在办的分配」),
   ⛔ 不是 plan.assignment_id 非空 —— 后者在退回后仍留着(那是退回率的分母),
   此时客服自己捞回来打的电话会被算进一个早就结束的批次。

2) detail 增加 outcomes:success / failed / keep / noOutcome / byOutcome / note
   · 每个患者只取最近一次执行(DISTINCT ON) —— 打三次才约上是一个成功不是三个
   · noOutcome 单独成桶:那不是效果差,是根本没做/没记。并进 failed 会把执行问题
     读成召回问题,而两者要改的东西相反
   · 四桶穷尽 success+failed+keep+noOutcome === planned

3) ⛔ outcomes 与 releaseReasons 不能互相顶替(工具描述里也写死了)
   releaseReasons = 没打就还回去(分配问题);outcomes = 打了结果这样(召回效果问题)

写这一版时踩了一次:noOutcome 里多减了 reassigned → 被压成 0。
「现在归谁」与「做没做」是正交维度,不能放进同一个减法。已加回归锁住。

实测(真库):3 人批次打 refused + no_answer → 执行带批次号落库 →
详情读出「成功 0 · 不成功 1 · 打了没进展 1 · 一次结果都没有 1」,四桶合计 3 === planned 3,
明细「明确拒绝 1」,note 自带样本不足与「成功含约定下次回访」两条护栏。
1020 tests,两个 tsc 干净。