fix(vendor-channels): 修复 zhipu→anthropic 通道 tool_use/tool_result 配对漏洞

[ThreeFish-AI]

背景

zhipu → anthropic 通道流式请求偶发 400:

messages.3: `tool_use` ids were found without `tool_result` blocks immediately after: toolu_normalized_2.

同一请求带 rewritten_N_srvtoolu_ids + misplaced_tool_result_relocated 但没有 orphaned_tool_use_repaired——转换层主观认为已配对、Anthropic 仍判定结构不合规。Failover 至 zhipu 后请求成功，证明上游消息体没坏，问题出在跨供应商转换过程引入了不一致。

根因

_rewrite_srvtoolu_ids 旧实现是单遍循环同时承担两件事：Case A 改写 assistant 端的 server_tool_use + srvtoolu_* ID、Case B 同步改写任意位置 tool_result.tool_use_id。Case B 依赖 id_map 已被 Case A 填入。

GLM-5 流式响应偶发将 inline tool_result 输出在对应 server_tool_use 之前（同 assistant content 内乱序），或将 tool_result 放在更早的 user 消息而对应 tool_use 在更晚的 assistant 消息。两种乱序下单遍扫描遍历到 tool_result 时 id_map 还是空 → tool_use_id 漏改、停留在 srvtoolu_*。随后 enforce_anthropic_tool_pairing 以旧 ID 作 extracted_tool_results 的 key、用新 ID 去查不命中，misplaced tool_result 被默默丢弃，最终 Anthropic 400。

修复

1. _rewrite_srvtoolu_ids 改两遍扫描：Pass 1 仅遍历 assistant 收集 id_map（按出现顺序分配，保持序号兼容）；Pass 2 全量遍历改写任意 tool_result.tool_use_id。以"先建表、后改写"次序消除时序耦合。
2. 新增 _enforce_pairing_sanity_pass 独立 helper：作为 enforce_anthropic_tool_pairing 主循环末尾的纵深防御层，仅做检测 + 合成 is_error=True 占位（不剥离、不重定位），命中追加 pairing_sanity_repaired 并 WARNING。在主循环未来重构时仍能稳定守住 Anthropic 配对约束。
3. 回归测试覆盖三类场景：同 assistant content 内乱序、跨消息边界 tool_result 早于 tool_use、端到端复现日志故障形态；并新增 TestEnforcePairingSanityPass 独立测试套件确保兜底分支具备正向回归保护。

实现要点

• Pass 1 / Pass 2 注释中显式标注次序意图与单遍漏改的失败模式，规避未来"无意优化合并"重新引入 bug。
• Sanity helper 单独抽出而非内嵌主路径：避免主路径快速通道让 sanity 分支永远走不到正向测试（历史教训：9061cd0 曾实现两遍扫描+sanity，但 2bac9a7 因缺乏对兜底路径的独立单测被连带回滚）。
• adaptations 标签 pairing_sanity_repaired 与主循环 orphaned_tool_use_repaired 分离，便于运维按层归因。
• 同步在 docs/issue.md 记录根因、处理方式、后续防范与同类问题回滚红线（grep _enforce_pairing_sanity_pass / Pass 1 / Pass 2）。

验证

• uv run pytest tests/test_vendor_channels.py：84 passed
• 新增 10 个用例覆盖两遍扫描、sanity 兜底与端到端配对不变量

🤖 Generated with Claude Code, CodeX, Gemini
Co-Authored-By: Aurelius Huangthreefish.ai@gmail.com