产品定。理由是**分配的语义**:
  · **主管分配的意思是有始有终** —— 他决定了这批人交给谁,那就该在他手上走完;
    回池等于把这个决定作废、再重新分一次。
  · **容许客服短时超期** —— 没按时打完是常态不是异常,给缓冲让他继续跟进。
  · **减少客服之间的调度** —— 回池再分会让同一批患者在人之间来回换手,而换手本身有成本。
⚠️ ⛔ 别用测试服的落人分布给这条"补证据":那是种子数据,说明不了真实运营。
  这条站在语义上,不站在概率上。

── 行为 ────────────────────────────────────────────────────────
`AssignmentExpiryScheduler` **整个删掉**(⛔ 不是翻 PAC_ASSIGNMENT_EXPIRY):
时限到了什么都不发生 —— 状态不变、归属不变,只是从此算「超期」。
墓碑与沿革写在 `plan.module.ts` 上,原实现与那 10 条用例在 git 里。
⚠️ 单子回池仍有两条路,都是**人主动做的**:客服退回、主管撤销(限时 30 分钟)。

⚠️ 连带成立、⛔ 别当 bug 修:①「在手」只增不减 —— 那是真的还压在他手上,
  产品要看的就是整体负载(⛔ **不拆**成"时限内/超期"两个数);
  ②「最忙的那位」会常亮 —— 它本来就是工作量预估不是异常告警。

── 🔴 超期换了源(最容易静默出错的一处)────────────────────────
从此不会再有新的 `auto_release/assignment_expired` 事件。只数账本的话,
**08-19 之后每个批次这一列都永远是 0**,而主管看到的是"这批没人超期"。
⇒ 批次的 `expired` 改成**取并集**:账本里到期回收过的(历史) ∪ 此刻仍挂在人手上
  且已过时限的(现状),与 `workload()` 那两支同一套算法。三条新用例钉住。

── 文案统一口径(⛔「回池」不再出现在与"到期"相关的任何一句里)──────
退场:自动退回 / 落回池子 / 到期回池 / 即将退回池子
在用:**时限**(几天内打完)· **超期**(过了时限还没处置,单子仍在他手上)
  · 引导节点「不处理会怎样」→「就按 N 天发;超过这个天数没打完的记为超期,单子仍在这位客服手上」
  · propose_assignment 的 expiresInDays 描述(模型会照着念)→「要在几天内打完;
    过了不会被收走,仍在原来那位客服手上,只是记为超期」
  · 确认单右上角「N 天后自动退回」→「N 天内打完」
  · 客服执行页「已过期 · 即将退回池子」→「已超期」;「还剩 3 天退回」→「还剩 3 天」
  · 批次列头「到期回池」→「超期」
⚠️ 「退回」这个词**没有全禁** —— 客服主动退回、主管撤销确实会回池,那两条路照旧。

── 工作台的超期提醒加强 ────────────────────────────────────────
· 抬头多一句「其中 N 条已超期」—— 一个人 41 条不吓人,全队 196 条是另一回事
· 超期那一格带上「最久 N 天」(新增 `overdueOldestDays`)—— 昨天刚过时限的 41 条
  和压了 12 天的 41 条,该做的事完全不同

存量不用管:分配功能还没正式上线。

验证:1354 passed,两个 app 的 tsc 绿,next build 通过。

⚠️ 顺手修了一处**上一个提交漏掉的**:`mcp-clinic-scope` 扫源码断言 `本批福利: benefit.trim()`,
  而福利浮层那次把它改成了 `benefitNow` —— 那次只跑了 tsc/build,没跑 jest。

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