[Corden404]

关联 #1170（F07）、#1242

问题与改动

同步 Computer 请求失去等待方后仍可能从 Registry 队列派发；超时收尾还存在接收端提前释放、未派发证据被其他清理路径移除的竞态。不同取消入口的终止追踪也不一致。

本修改：

• 在出队锁内清理未派发、无 Job 身份且等待方已关闭的 Computer 请求。
• 使用借用形式的 timeout，保持接收端所有权直到超时收尾读取派发状态，保留 not_started 与未知结果的区别。
• 统一 poll、失去等待方的同步请求清理和显式取消入口，记录 tool_runner_request_cancelled，包含 request_id、dispatched，以及 waiter_closed / explicit_cancel 有界原因，随后完成同步请求 correlation 收尾。
• 保留出队排队时长证据，更新 Computer Use 文档中的阶段与证据边界。

回归覆盖

• ToolRuntime 超时调用链：确定性控制 Registry 锁竞争，验证收尾前不会丢失未派发证据。
• Streaming 调用链：实际 spawn_request_pump() / poll_for_connection()，覆盖 WebSocket、QUIC 连接租约和有界 channel 背压。
• Registry → 生产 Telemetry 适配器 → Trace：覆盖三个取消入口、派发前后状态、准确 correlation 收尾及元数据隐私。

验证

受检提交：023d18c7cdeac22960b3e172ae2e16f35ca90404，构建时工作区干净。

• 超时收尾和取消 trace 两个新增回归在受检基线 1660961 上失败，在最终候选通过。
• Registry：380 项通过，1 项既有忽略。
• Server 聚焦测试：143 项通过；合计 523 项不同测试通过。
• cargo fmt、git diff --check、Markdown 本地链接检查通过。
• 从准确提交构建新的 dogfood Server / Runner / CLI。
• ChatGPT 真实 Host 验收全部使用 Extra High / 极高，复用原 tunnel。受控慢只读请求在派发后、结果捕获前 Stop，最终返回失败结果；约 154 秒观察期无新增迟到只读请求。同一 ClientWindow 的后续运行状态查询和窗口观察成功。
• 验收后已恢复原运行时，tunnel 进程保持不变。
• fork CI：撰写时仍在运行，发布前更新准确提交的最终结果。
  https://github.com/Corden404/webcodex/actions/runs/39569702452

范围

Registry 出队并标记派发之后，即使请求仍受 channel 背压阻塞，关闭等待方也不能证明它尚未进入传输。因此继续保留已派发状态，不新增效果重放或物理取消保证。

当前 PR 实现了队列清理、超时证据保留、取消追踪；F07 的解决仍需完成原始迟到现象的阶段归因、相应修复和固定条件复测。

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[swjnxyf]

Reviewed PR #1243 directly on MSI at aae5e956504b7e8f6f69ffc1b58d023180debd46.

The cancellation race is handled at the correct Runner Registry authority boundary. Before dequeue/dispatch, only a synchronous Computer request with no durable Job identity, a closed exact waiter, and dispatched=false is retired. Once dispatched, waiting-client loss remains uncertain; the implementation makes no claim of native cancellation, wire receipt, or effect replay safety. The tokio::time::timeout(..., &mut receiver) change retains waiter ownership through dispatch-certainty cleanup under the Registry lock, preventing abandoned-request sweeps from erasing not_started evidence.

I checked all three cancellation paths (poll, abandoned sweep, explicit cancel), bounded waiter_closed/explicit_cancel telemetry, the ordering of cancellation event before exact synchronous correlation finalization, preservation of durable Job ownership, and metadata-only/no-body trace projection. The WebSocket/QUIC streaming backpressure tests deliberately distinguish Registry dequeue from writer-channel transmission. No additional authority or automated re-dispatch was introduced.

Independent MSI tests:

• cargo test -p webcodex-runner-registry --lib --offline: 380 passed, 1 ignored.
• ToolRuntime timeout ownership race, WS/QUIC streaming backpressure, and exact-correlation cancellation regressions: 3 passed.
• cargo test -p webcodex computer --lib --offline: 76 passed (including the dedicated tests above).
• cargo test -p webcodex tool_request_trace --lib --offline: 47 passed; exact queue metadata privacy test also independently passed.
• cargo fmt --all -- --check, git diff --check, and Markdown local links (1,129 checked; 0 missing): passed.
• Exact-head GitHub Actions CI: 18/18 jobs succeeded, and no unresolved review threads.

No blocking findings, no corrective commits necessary. Approved for squash merge. This PR addresses queue cleanup, timeout evidence, and cancellation telemetry, but does not claim to fully resolve the broader F07 / #1170 original late-observation investigation.