修复盲区：已关闭轮次中的悬挂 tool_calls 不会被补齐，导致会话永久不可用

[byteMa0924]

现象

一个会话在 v0 迁移到 v3 之后，每次发消息都被 provider 拒绝：

An assistant message with 'tool_calls' must be followed by tool messages
responding to each 'tool_call_id'. (insufficient tool messages following
tool_calls message) [INVALID_REQUEST]

会话因此永久不可用。

环境

• DSH 0.1.6-alpha.2 (ddefc45, master)
• Node v24.16.0, win32 x64
• Profile: web

复现

1. 某轮里 assistant 发出 tool_calls，但该轮在工具结果落盘前被中断，
   此时 step/end 与 turn/end 已写入，tool/result 缺失。
2. 之后在同一会话发新消息。
3. 请求被持续拒绝，会话不可恢复。

实测定位（session-31f06a86-a425-4466-9968-e5fc21638fef）：

[681] user/message
[682] assistant/message tool_calls: pwsh, job_list
[683] tool/call 仅调用记录，无结果
[684] step/end
[685] turn/end
[686] session/end-seed
[687] turn/start
[691] user/message

该会话共 109 条带 tool_calls 的 assistant 消息，只有这一条没有配套
tool/result。缺失的 callId：

call_00_aHlYRLVwtbX85uYH71LL2751
call_01_IHkwxtP6F93M25KplUGT1624

根因

packages/core/session/src/repair.ts

• 第 50-53 行：case 'step/end' 执行 pendingCalls.clear()，待修复集合被清空。
• 第 82 行：if (openTurn === null || last === undefined) return []
  修复只在最后一个轮次仍未关闭时运行。

二者叠加：任何在已关闭轮次中遗留的悬挂 tool_calls，既不会被记录进
pendingCalls，也不会进入尾部修复路径，因此永久停留在日志中。该结构不是
崩溃残留，而是已正常收尾的轮次中的畸形历史。

预期行为

按 packages/core/session/README.md:154 的既定契约，持久化 tool/call 无结果
时应补为 TOOL_OUTCOME_UNKNOWN 合成结果。该路径对历史上已关闭的轮次也应
生效；或在写入时阻止 step/end / turn/end 在不平衡状态下落盘。

补充

该会话的 v0→v3 迁移本身完全通过（transformed 与 current 两种 validation
均 OK），说明迁移层不是成因。畸形结构在迁移前后都存在，只是新 loop 组装
请求时被 provider 的严格校验拦下。

[xiaoyuyu6420]

你这份数据把「修复盲区」钉得很准：interruptedTurnClosers 只处理尾部未闭合轮次，历史中段的悬挂 pair（无论是崩溃产物 #6127、prepare 波产物 #7129，还是你这种迁移产物）它都碰不到。修复前给你三条按侵入度排序的路：

1. 立即解堵，不动数据：这个 400 来自 provider 侧的严格配对校验，不是所有 provider 都查。把该会话的路由切到一个不做配对校验的 provider/模型上，会话立即可用（#6127 里有"切回原 provider 即恢复正常"的实测）。代价是暂时换模型。

2. 数据侧修复 A（改动最小）：把受损 assistant/message 的 content 里那些没有结果的 tool-call 块剥掉。好处是不碰事件序——不需要重编号。zstd 容器是逐帧独立的：目标消息落在哪个帧就只重编那个帧，其余帧字节不动。代价：模型可见历史里这些调用记录消失（恢复场景通常可接受）。

3. 数据侧修复 B（最重，不建议手做）：在每个悬挂 tool/call 后补合成 tool/result（isError 占位）——这是历史中段插事件，意味着后续全部事件重编号，且必须同步重映射所有 sourceEventSeqs 引用。#6348 就是"只改了 seq 没同步溯源数组"被新校验拒绝的先例，手工做几乎必踩。

官方侧的长期解就是你说的 sanitizer（serialize 前补齐/剥离）或 repair 扩展到非尾部轮次。建议把 #6127、#7129、#7257 三帖一起引用——三代同族、两种成因（崩溃产物/迁移产物），正好说明这不是单点 bug 而是一个缺位的机制。