求实测:PR #256 Orca lead 排队消息管理(作者未做运行时端到端验证)

## 背景

PR makecindy/cindy-temp#256 给 Orca 协同加了「lead 管理 worker 排队消息」的能力:lead 派的消息在 worker 忙时排队后,现在可以列出(`list_worker_queue`)、整条改写(`update_queued_message`)、撤回(`cancel_queued_message`),`send_to_worker` / `create_worker`(initial_task)排队时会回传 `queued_message_id` 句柄。

**如实说明:我自己没有做过运行时实测。** 目前的验证只有:仓库根 `pnpm test:unit` 全量门禁绿、service 层错误码矩阵与 settle 路径的单测、desktop / lizi-mcps typecheck。真实双 agent 协同场景下的端到端行为(尤其 UI 联动和真实 drain 时序)没人跑过,希望有同事帮忙实测一轮。

## 希望验证的路径

环境:checkout 分支 `dash/orca-queued-message-control`(或 PR 合并后的 main),`pnpm restart:desktop:remote` 起 dev。

**主流程:**
1. 开协同,创建一个 worker,先派一个耗时任务让它忙起来。
2. worker 忙时让 lead 再 `send_to_worker` 一条 → 确认返回 `wake_kind=queued` 且带 `queued_message_id`,同时 worker 会话 UI 里能看到这条排队消息。
3. lead 调 `list_worker_queue` → 队列条目、来源(source)、正文、位置是否与 UI 一致。
4. lead 调 `update_queued_message` 改写正文 → UI 排队气泡应同步更新;等 worker 空闲后消费的应是**改后**内容,消息头格式(`[From Orca Lead]` + worker_id 桥注)应与正常派发一致。
5. lead 调 `cancel_queued_message` → UI 条目消失,worker 空闲后不再收到该消息。

**边界与健壮性:**
6. 用户在 UI 手打一条消息排进同一队列 → lead `list_worker_queue` 能看到(source=user 含正文),但 update/cancel 它应返回 `NOT_LEAD_MESSAGE`。
7. 消息已被 worker 消费后再 update/cancel → 应返回 `QUEUED_MESSAGE_NOT_FOUND`,不产生副作用。
8. 撤回一条排队消息后观察 worker 状态:不应被误标 `running`,后续 turn 结束的 auto-bridge 行为应正常(关注 `apps/desktop/logs/` 里有无 orca 相关异常)。
9. 有排队消息时重启 app → 崩溃恢复快照读回后,lead 对恢复出的条目 list/update/cancel 是否仍工作。
10. (可选)Codex lead 与 Claude lead 各跑一遍主流程——两种 lead 的 MCP context 路由不同。

发现问题直接在本 issue 或 PR makecindy/cindy-temp#256 上反馈即可。

Check out dash/orca-queued-message-control or the merged main branch, then run pnpm restart:desktop:remote and exercise the listed lead/worker queue flows, including UI updates, cancellation, draining, and recovery. Compare tool results with the worker session UI and inspect apps/desktop/logs/ for Orca errors; done means reporting the pass/fail behavior of the required scenarios, with optional Codex and Claude runs.

Written by the indexing model from the issue text.