修复分支审查发现的三处问题

一、流式工具槽位按 id 归位，消除终态载荷错位产生的重复调用

extract_responses_completed_tool_fragments 用 output[] 数组下标当槽位，而增量
路径用事件自带的 output_index。网关若在 completed 快照里省掉此前占用过某个
output_index 的 reasoning / message 条目，两者基准就错位，终态分片会落进一个
从未占用过的空槽位。空槽位上 merge_tool_identity 的 current 为 None、冲突检测
不触发，于是静默产出两条 id 完全相同的调用。

探针实测：output_index=1 的调用 + 只含一个 function_call 的 completed 载荷，
返回 Ok 且 tool_calls 为两条一模一样的 call_a/get_weather，零告警。

这说明 872a2f645 的身份冲突修复是不完整的——它只堵了「撞上已占用槽位」，没堵
「落进空槽位」。改为在 push_tool_fragment 里先按非空 id 归位到已有槽位：槽位只是
传输层归并键，真正的身份是 id。名字冲突仍由 merge_tool_identity 拦截，并进去之后
函数名不一致照常失败关闭。

下游影响：本仓库 agent_native_tools.rs:308 按 call id 唯一性校验，重复即报
CallIdentity 错误，所以现状是合法响应被误判成协议错误、空耗格式修复配额，不是
重复执行。但 platform-llm 是给 module-ai / module-story 等复用的基础 crate，
不能指望每个消费方自己去重，故在 crate 层修。

二、补回 check-native-shells 丢失的 App.tsx iframe 断言

85b9c2f19 合并 codex 时，check-native-shells.mjs 的 assertAiGameCreatorShell-
UserDevBoundary 双方独立重写产生冲突，当时判定「我方是上游的严格超集」并整段取
我方——这个判断是错的。上游有一条我方没有：App.tsx 全文不得直接出现 <iframe>，
预览必须委托给客户端工作台。我方版本只约束 DeveloperProjectPanels 自身的 iframe
数量与挂载位置，管不到外壳自己内嵌预览框。

补回该断言并反向验证：往 App.tsx 塞一个 iframe 后门禁确实报错，移除后通过。

三、流式工具校验失败分支落盘真实 attempt

stream_run 新增的四处工具调用后置校验失败分支（截断门禁、finish_tool_calls
失败、不完整终态拒绝、一致性断言）调用 log_llm_raw_failure 时把 attempt 硬编码成
字面量 1，同函数其余 12 处均传真实 attempt。重试后落盘日志全部标成第一次尝试，
排障时看不出真实次数。

隔离验证：停用按 id 归位后，两条新增用例转红；第三条（不同 id 的并行调用必须保持
两条）两边均绿，它守的是归并不得过头。

platform-llm 106 passed（原 103）。

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

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

@@ -277,7 +277,7 @@ Responses 的终态载荷既是工具调用的恢复源，也是正文的恢复
 
 工具事件的协议槽位缺失时必须失败关闭，不得跳过也不得按事件内位置猜测：槽位是并行分片唯一的归并依据。跳过会静默丢掉整个调用——只剩一个调用时才可能被 `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` 为空串，按“不等即冲突”会把它们整批误杀，这也与归一层的空白即缺失约定一致。
+槽位存在但被两个不同调用共用时同样必须失败关闭：同一槽位的 id 与函数名只允许**从缺失变为已知**或**重复同一个值**，出现互不相同的非空值即返回 `Deserialize`。“覆盖身份、追加参数”并不自洽——前一个调用参数为空时拼接结果就是后一个调用的合法 JSON，参数完整性检查兜不住，调用方只会拿到后一个工具，前一个静默消失；Responses 的权威完整参数还会整段覆盖，产出“前一个调用的身份配后一个调用的参数”。两者都会原样交给 Runtime 执行。已知触发路径有两条：兼容网关把 Chat 的 `index` 恒置 0，以及 Responses 的 `response.completed` 回退按 `output[]` 下标重建槽位时与流式 `output_index` 基准错位（例如 completed 载荷省略 reasoning item）。id 必须与函数名一同参与判定——并行调用同一个工具是最常见的并行场景，此时函数名相同，只有 id 能区分。槽位本身只是传输层的归并键，真正的调用身份是 id：同一个非空 id 落到两个槽位只可能是上游在不同事件里用了不同的槽位基准（Responses 的终态载荷按 `output[]` 数组下标重建槽位，网关若在快照里省掉此前占用过某个 `output_index` 的 reasoning / message 条目就会与增量事件错位），此时必须按 id 归位到已有槽位，不能新建。按新槽位新建会产出两条 id 完全相同的重复调用，而且因为落进的是空槽位、同槽位冲突检测根本不触发，全程无告警；下游按 id 唯一性校验的消费方会把这种合法响应误判成协议错误并空耗格式修复配额，不做该校验的消费方则会重复执行同一个工具。按 id 归位不放松身份校验——并进已有槽位后函数名不一致仍照常失败关闭。空白身份按缺失跳过、不算冲突：部分兼容网关在续传分片里回发完整 `function` 对象且 `name` / `id` 为空串，按“不等即冲突”会把它们整批误杀，这也与归一层的空白即缺失约定一致。
 
 工具参数字段必须区分“缺失”与“类型非法”：字段不存在或为 `null` 是合法缺省（零参函数），存在但不是字符串一律返回 `Deserialize`。把两者混同的写法（`as_str` 遇到非字符串返回 `None`）会让参数被当成缺省，归一层再补成 `{}`，于是一个身份完整、参数是合法 JSON 的调用直接交给下游执行，既有校验全都拦不住——零参函数的 `{}` 与“参数类型错了所以变成 `{}`”在归一层无法区分。涉及 Responses 的 `response.function_call_arguments.delta` 的 `delta`、`.done` 的 `arguments`、终态载荷 `output[].arguments`，以及 Anthropic `input_json_delta` 的 `partial_json`；Chat 走强类型 DTO，同样输入本就反序列化失败，本规则是把三协议口径拉齐。该约束只覆盖参数字段：id 与函数名即使类型不对也只会退化成缺失，随后被归一层按缺 id / 缺函数名拒绝，本来就是失败关闭。