主管实测:助手撤销必挂,报「批次 c02e1b80 不存在」。

根因不在撤销,在确认后注入消息流的那句话:
`已确认分配:批次 #${id.slice(0,8)}` —— 界面与模型共用这一份,
模型手里只有 8 位短号,拿短号查主键当然查不到。
卡片上的撤销按钮握着完整 id 一直是好的,所以只测卡片那条就漏了。

修法两层:
- 文本块加 modelText:界面显示一份、喂模型一份(后者带完整 uuid);
  界面顺带不再显示批次号(uuid 对主管没有意义)
- 服务端 resolveAssignmentId 兜底认短号,并能从「批次 #c02e1b80」
  这种整句里抠出 id(实测模型就这么传);撞到多个报错不猜

追查中发现更严重的一个:助手会把「已撤销批次:收回 9 条。」**背出来** ——
没调 revoke_assignment,库里那批仍是 confirmed、9 条工单一条没动。
工具返回被设计成"成品句子、原话转述",模型学会形状后就能凭空生成。
报错主管会重试,假成功会让他停止补救。

⇒ 前端每轮结束对账:主管在要求撤销 + 助手自称撤成了 + 本轮没有
  revoke_assignment 的 tool_result ⇒ 把事实贴出来。
  措辞只陈述观察(不断言撒谎):主管问"刚才那批撤了吗"时如实回顾也不调工具。

实测:短号经模型这条路已跑通(a7e1b6de → revoked,9 条回池无认领人)。
996 tests,两个 tsc + next build 干净。