fix(protocol): give every announced responses item a unique output_index and its own order

[argszero]

Summary

The streamed openai_chat → responses translator gave two different items the same output_index, and its terminal object listed the items in an order contrary to its own incremental events.

ResponsesStreamState announced the message item at a hardcoded output_index: 0 while tool_output_index also started at 0, so a response carrying text + a tool call announced two items at index 0. A client that tracks items by output_index — the key the Responses protocol gives for exactly this purpose — has one item overwrite the other, usually the function_call an agent client then waits forever for. The terminal response.output was composed by the whole-body helper (function_call first, message last), which contradicts the order in which the stream had announced them.

Measured on the streamed path (text + two tool calls, after the fix):

item announcements (id, output_index): [("msg_c1", 0), ("fc_call_1", 1), ("fc_call_2", 2)]

and with the colliding indexing reinstated (positive control below):

assertion `left == right` failed: 索引必须互不相同：[0, 0, 1]

This survived until now because the shape-parity test added in #206 only compared the streamed terminal object with the whole-body one — never the stream's own events with its terminal.

Related Issue

Changes

• 功能/修复说明 — 每个被宣布的条目从同一个单调计数器拿到 output_index（message 条目先，随后各 function_call），因此索引唯一、单调，且就是该条目在 output 数组里的位置；tool_output_index 那套 +1 / saturating_sub(1) 算术删掉
• 功能/修复说明 — message 条目改为第一次拿到文本时宣布（此前在初始化块里无条件宣布）：于是「流宣布过的条目」与「终局列出的条目」是同一个集合，没有文本就没有这个条目（与整包路径一致）
• 功能/修复说明 — 终局 output 按宣布顺序拼装（流自己的权威）；整包路径的顺序不变（function_call 在前），形状仍同源
• 功能/修复说明 — 每个 function_call 的 response.function_call_arguments.delta 用它自己的索引（旧算术对「同一 chunk 里第二个工具调用」和「同一 call id 的续块」都会给出错的索引）
• 功能/修复说明 — 条目形状拆成按条目的唯一真源 protocol::openai_chat_message_item / protocol::openai_chat_tool_call_item，两条路径共用；openai_chat_message_to_responses_output 改为调用它们（整包行为不变）
• 涉及配置/数据结构的改动已同步示例文件 — 不涉及（无 config / schema / ui/ / i18n 改动）

Tests

• cargo test 全部通过 — 199 passed（原 196，+3）
• cargo fmt --check 通过
• 新增/更新了单元测试（如适用）
  • responses_item_indices_are_unique_and_match_the_announced_order — 文本 + 两个工具调用 ⇒ 三个条目的索引多重集为 {0,1,2} 且按宣布顺序单调递增；终局 output 的 id 序列 == 宣布顺序；每个参数增量的 output_index == 它自己条目的索引（含同一 chunk 内两个工具调用、同一 call id 的续块）
  • responses_items_follow_the_announcement_order_when_tool_calls_come_first — 顺序规则是宣布顺序，不是「message 永远第一」
  • responses_stream_without_content_announces_no_items — 不变式的边界：无内容 ⇒ 不宣布条目、终局 output 为空
  • responses_terminal_shape_agrees_between_stream_and_whole_body — 改为按身份（message / call_id）比对条目形状而不是按下标，并把两条路径各自的顺序规则写成显式断言（流式＝宣布顺序，整包＝工具调用在前）
  • responses_terminal_event_is_emitted_once_with_the_full_response_object — 终局顺序期望随规则更新为 [message, function_call]

A/B（红前绿后，每条变异自带期望红集，还原在 finally，mtime 已刷新）

变异	期望红集	实测
索引撞车（message 条目写死 0）	索引唯一性 + 工具调用先到	197 passed / 2 red（= 期望）
终局按整包顺序拼装	唯一性 + 终局事件测试 + parity	196 passed / 3 red（= 期望）
参数增量用旧 next_output_index-1	索引唯一性	198 passed / 1 red（= 期望）

还原后 199 passed 全绿，且两个源文件 md5 与注入前逐字节相同。

Checklist

• 分支命名符合约定（fix/responses-output-item-index）
• Commit message 使用 Conventional Commits 格式（fix(protocol): ...）
• 单一职责，改动最小化 — 只动 src/sse.rs + src/protocol.rs 的 responses 流式条目身份/顺序；status／截断语义（face ④）与初始化门（F1，可达性未证）刻意不动