Responses 终态事件恢复正文

response.completed / incomplete 分支只从终态载荷恢复工具调用，不恢复
message.content[].output_text，导致三种后果（均已实测复现）：

- 纯文本的 completed-only 响应 -> EmptyResponse，上层白跑一轮重试或降级
- response.incomplete 携带的截断正文同样退化成 EmptyResponse，连降级
  回复都给不出来
- 「正文 + 工具调用」响应不报错，但模型的前置说明被静默丢掉，最隐蔽

有增量事件的正常流和非流式路径都不受影响。

归属：终态载荷成为「恢复源」是本分支 7c61e9a53 确立的，它加了
extract_responses_completed_tool_fragments 却没同步提取正文，且同一提交新增
的回归载荷里带着「我来查询。」而只断言 tool_calls，缺陷被自己的测试盖住；
fc53ee5c9 把 incomplete 并进同一分支时把这个不对称一起带了过去。更早的
9d684cb7b 虽然也没提正文，但那时终态载荷根本不是恢复源。

修法：ParsedStreamEvent 新增 text_snapshot，与 delta_text 分开——它不是增量，
按增量累加会让正文翻倍。终态分支把 response 反序列化成
ResponsesResponseEnvelope 后复用 extract_responses_text，不另写裸 JSON 提取器：
后者必然漏掉 reasoning / thinking 等隐藏 part 的过滤，会把思维链当正文吐出去。
反序列化失败按「没有快照」静默降级而非报错——兜底路径放过只是回到修复前行为，
与槽位缺失那类会造成静默错配的失败关闭口径不同。

累加时按状态分两条路：累加为空（只发终态事件的网关）把快照当成一次增量发出去，
否则 response.text 对了但调用方流式通道全程收不到文本（Responses 的
emit_finish_only_delta 为 false，只有 Chat 为真）；累加非空则按权威值覆盖且不
补发回调，避免调用方侧翻倍。覆盖语义与 arguments_complete 一致。

隔离验证两次：把 text_snapshot 置 None，四条用例转红；把覆盖改成追加，
不重复用例转红。

platform-llm 95 passed（原 91）。新增 completed-only 纯文本、incomplete-only
纯文本、delta 与终态并存不重复、终态 reasoning part 不入正文四条，并收紧既有的
stream_run_recovers_responses_tool_calls_from_completed_event_only 断言正文。
前两条同时断言 on_delta 实际回调内容，只断言 response.text 抓不到流式通道那个坑。

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

docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md

@@ -269,6 +269,10 @@ arguments 是否必须是完整 JSON **按流式与非流式区分，两者的
 
 各协议的最终事件必须同时终止读取循环，不能只标记完成：Chat 的 `data: [DONE]`、Responses 的 `response.completed` 与 `response.incomplete`、Anthropic 的 `message_stop` 都置终止位。Responses 的整体收尾信号有两个——撞到 `max_output_tokens` 时上游**只发 `response.incomplete`、不发 `response.completed`**（真实端点抓包确认），其载荷与 completed 同构，同样带完整 `output[]`，item 上标 `status=incomplete`，`incomplete_details.reason` 给出原因。漏掉它会同时造成三件事：不终止读取循环、流式 Responses 永远产生不出 `incomplete` 这个 `finish_reason`（上面那条截断拒绝规则对它形同虚设）、只在整体终态事件中携带的工具调用被静默丢掉。服务端在最终事件后保持连接（keep-alive、SSE 网关不主动关流）时，只标记完成会让读取一路等到调用方超时。
 
+Responses 的终态载荷既是工具调用的恢复源，也是正文的恢复源，两者必须对称。只恢复工具会造成三种后果：纯文本的 completed-only 响应退化成 `EmptyResponse`（上层白跑一轮重试或降级）；`response.incomplete` 携带的截断正文本来是可用的降级结果，同样拿不回来；“正文 + 工具调用”的响应不报错，但模型的前置说明被静默丢掉，最隐蔽。正文提取必须复用非流式那条路径（`output_text` 优先、`output[].content[]` 回退、过滤 `reasoning` / `reasoning_content` / `analysis` / `thinking` 等隐藏 part），不得另写裸 JSON 提取器——漏掉过滤层会把思维链当正文吐给调用方。终态载荷反序列化失败时按“没有快照”静默降级、不报错：这是兜底恢复路径，网关发出未建模的形状时应当退回增量累加结果；这与槽位缺失必须失败关闭的口径不同，那里放过会造成静默的身份与参数错配，这里放过只是回到没有该恢复路径时的行为。
+
+终态正文按**快照覆盖**而非追加合并，且要按累加状态分两条路：累加为空时（只发终态事件的网关）必须把快照当作一次增量发出去，只覆盖累加值会让调用方的流式通道全程收不到任何文本——Responses 的 finish-only 回调开关是关闭的，只有 Chat 打开，指望终态回调兜底并不成立；累加非空时按权威值覆盖但不补发回调，否则正文在调用方侧翻倍。覆盖语义与工具参数的 `arguments_complete` 一致。
+
 工具事件的协议槽位缺失时必须失败关闭，不得跳过也不得按事件内位置猜测：槽位是并行分片唯一的归并依据。跳过会静默丢掉整个调用——只剩一个调用时才可能被 `StreamUnavailable` 断言兜住，丢一半毫无察觉；Responses 的整体终态原因是 `completed` / `incomplete`，也不会触发只识别 `tool_use` / `tool_calls` 的那道断言。猜测则会把两个不同调用合并成一个混合体（后者的 id / name 覆盖前者，arguments 被拼接）。判定字段为 Chat 的 `delta.tool_calls[].index`、Responses 的 `output_index`、Anthropic 的 content block `index`。该约束只覆盖工具事件，纯文本增量不依赖槽位，不受影响。
 
 槽位存在但被两个不同调用共用时同样必须失败关闭：同一槽位的 id 与函数名只允许**从缺失变为已知**或**重复同一个值**，出现互不相同的非空值即返回 `Deserialize`。“覆盖身份、追加参数”并不自洽——前一个调用参数为空时拼接结果就是后一个调用的合法 JSON，参数完整性检查兜不住，调用方只会拿到后一个工具，前一个静默消失；Responses 的权威完整参数还会整段覆盖，产出“前一个调用的身份配后一个调用的参数”。两者都会原样交给 Runtime 执行。已知触发路径有两条：兼容网关把 Chat 的 `index` 恒置 0，以及 Responses 的 `response.completed` 回退按 `output[]` 下标重建槽位时与流式 `output_index` 基准错位（例如 completed 载荷省略 reasoning item）。id 必须与函数名一同参与判定——并行调用同一个工具是最常见的并行场景，此时函数名相同，只有 id 能区分。空白身份按缺失跳过、不算冲突：部分兼容网关在续传分片里回发完整 `function` 对象且 `name` / `id` 为空串，按“不等即冲突”会把它们整批误杀，这也与归一层的空白即缺失约定一致。