修复第三方 Provider 流式工具计划请求 (#201)

## 变更摘要

- 当 Provider 配置 `llm.stream=true` 时，Provider tool-plan 请求改为使用 `stream_run`，由后端聚合完整响应；关闭流式时继续使用 `run`。
- 补充 Anthropic 原生 SSE 工具调用、原生最终回复和 OpenAI 响应流测试夹具。
- 新增流式原生函数工具计划回归测试，覆盖请求 `stream=true`、工具调用聚合、respond_to_user 收束和最终回复请求。
- 修复共享 Provider 测试夹具对 `stream=true` 的 Responses / Chat Completions 请求返回正确 SSE，避免时序测试误报 Timeout。
- 修正自主构建截断 scaffold 修复分支的错误前缀匹配，并补齐最终回复失败审计夹具的流式 planning 响应。
- 同步第三方 Provider 兼容性技术说明，记录缺陷 5 已修复。

## 验证

已通过：
- 5 个 Provider handoff/retry/restart 回归用例（逐项运行）
- `autonomous_game_build_repairs_truncated_scaffold_into_bounded_patch`
- `background_agent_runtime_asset_generation_respects_project_policy`
- `background_final_reply_failure_keeps_private_conversation_and_hashes_public_audits`
- `npm run ai-game-creator-shell:typecheck`
- `npm run check:encoding`
- `git diff --check`

说明：Provider handoff 重启用例在并发启动时曾出现一次时序失败，单独串行复跑通过；当前提交已通过 pre-push 检查。`cargo fmt --check` 仍会报告基线其他文件已有格式差异，本 PR 未改动这些无关文件。

Close #186

---------

Co-authored-by: 段舒康 <kdletters@qq.com>
Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/201
Reviewed-by: 段舒康 <kdletters@qq.com>
Co-authored-by: suzmii <suzmii@qq.com>
Co-committed-by: suzmii <suzmii@qq.com>

docs/technical/【技术说明】AGC接第三方Provider的兼容性缺陷-2026-08-19.md

@@ -1,8 +1,8 @@
 # 【技术说明】AGC 接第三方 Provider 的兼容性缺陷
 
 - 首次记录：2026-08-19
-- 最新核对：2026-08-25，当前实现仍保留本文所述 Provider 分发约束
-- 结论：**这不是单一策划链路的问题**。各创作流程共用同一套 Provider 分发；第三方端点必须满足当前 `agentMode`、`apiKind` 和工具调用协议约束。缺陷 4 已修复，其余限制仍按本文处理。
+- 最新核对：2026-08-27，当前实现仍保留本文所述 Provider 分发约束
+- 结论：**这不是单一策划链路的问题**。各创作流程共用同一套 Provider 分发；第三方端点必须满足当前 `agentMode`、`apiKind` 和工具调用协议约束。缺陷 4 已修复；`llm.stream=true` 时 Provider tool-plan 现在按配置发送流式请求并在后端聚合完整响应，前端展示合同不变。其余限制仍按本文处理。
 
 ---
 
@@ -14,6 +14,7 @@
 | 2 | `codex_app_server` 模式把第三方端点喂给 codex | apiKind≠openai_responses 时秒挂；否则 413 + 工具误用，180 秒超时后留下待核对的孤儿请求 | 模式前提未被约束 |
 | 3 | `provider` 模式下 `tool_choice=required` 与 DeepSeek 思考模式互斥 | 首个 tool-plan 请求 400，整个 runtime 起不来 | 参数空间缺一个值 |
 | 4 | 普通 action 批次带 plan update 时，两条预检规则互斥 | 「更新计划 + 委派专业 Agent」同一轮返回就报「批次成员身份或顺序不匹配」 | **本分支回归**（已修） |
+| 5 | `llm.stream` 只记录配置，不驱动 Provider tool-plan 传输 | 要求 `stream=true` 的网关第一发 tool-plan 得到 HTTP 400，整轮不可用 | 传输配置失效（已修） |
 
 缺陷 1~3 叠加的结果：**当前代码里没有任何一组配置能让 DeepSeek 跑起来**。缺陷 4 与 provider 无关，换成 `gpt-5.6-terra` 打通 LLM 链路后才暴露出来。
 
@@ -291,3 +292,26 @@ let expected_member_plan_update = batch
 - DeepSeek 网关 413 的具体阈值，以及 `provider` 模式下 AGC 自组的请求体是否也会触顶。
 
 ---
+
+## 9. 缺陷 5：`llm.stream` 未作用于 Provider tool-plan（已修）
+
+### 现象
+
+`agentMode=provider`、`llm.stream=true` 时，审计与重试指纹记录 `stream=true`，但首个 tool-plan 仍调用 `LlmClient::run()`，请求体实际为 `stream=false`。只接受流式请求的 OpenAI 兼容网关返回 HTTP 400 `Stream must be set to true`；由于这是本地请求构造错误，重试同一请求无法恢复。
+
+### 修复边界
+
+Provider 的持久化重试分发与常规重试分发统一按 `llm.stream` 选择 `stream_run()` / `run()`。`stream_run()` 负责聚合文本、工具调用与终态，tool-plan 仍在响应完整后按现有协议解析、校验和交接；不把半截 tool-call 参数发布给前端，也不改变最终回复的 response-stream 合同。
+
+### 回归
+
+- `response_stream_uses_distinct_streamed_final_reply_for_responses_and_chat`：覆盖 Responses / Chat 两种 wire 的 tool-plan 与 final-reply 请求均发送 `stream=true`。
+- `response_stream_disabled_keeps_direct_planning_reply_to_one_request`：覆盖 `llm.stream=false` 时 tool-plan 仍发送 `stream=false` 且保持单请求直接收束。
+- `background_agent_runtime_executes_streamed_native_function_tool_plan`：覆盖 Anthropic tool-use 分片在 Shell Runtime 中聚合为原生工具动作，并完成 tool-plan 协议审计与动作执行。
+- `platform-llm` 既有 Chat / Responses 流式工具调用聚合用例继续覆盖分片工具参数装配。
+
+### 升级边界
+
+升级前遗留的 durable retry sidecar 若是在旧实现（审计记录 `stream=true`、实际发送 `stream=false`）期间创建，升级恢复后会按当前配置真实发送流式请求。该行为修正了配置与 wire 行为的一致性，但不保证与升级前已发出的失败请求字节一致；排查跨版本恢复时以 raw failure log 的请求快照为准。
+
+---