[reliability] codex 事件 broadcast ring 全 session 共享——并发 review 洪泛可致误 Failed（#35 follow-up）

[ghbvf]

背景

codex 事件 broadcast ring（capacity = 1024）在 src-tauri/src/review/engines/codex/process.rs 创建、由 src-tauri/src/review/session.rs 的各 session pump 共享订阅——全项目、全 session 共用一个 ring。

#35（多项目并行监听，PR #63）启用真并行后，N 个项目可并发跑 review。某个高-delta 的 review 若快速产出大量事件，可能洪泛共享 ring，使其它 session 的 pump 收到 Lagged → 被标记为 Failed——即使该 review 实际成功完成。

影响边界

• 不违反 [feat] 多项目并行监听 + 项目切换 UI（参考 codex app） #35「不串台」验收：事件仍按 thread_id / project_id 正确归属，不会串到错误项目/会话。
• 这是高并发下的鲁棒性退化（review 误失败），非正确性 / 串台缺陷。
• 该 ring 是 review 引擎既有机制（[feat] 多项目并行监听 + 项目切换 UI（参考 codex app） #35 之前单 session 已存在）；[feat] 多项目并行监听 + 项目切换 UI（参考 codex app） #35 只是提高了并发触达概率。

来源：PR #63 内置 6 维 review 的 reliability 维度 finding L1（pm:ship 评论 https://github.com/ghbvf/prmonitor/pull/63#issuecomment-4733058321）。当时判定为 large、非阻塞，经决策登单后续处理。

三级方案种子

• 最小：调大 ring capacity（如 4096）+ 注释说明并发上限假设。治标，降低触达概率，不解决根因。
• 彻底：per-session 独立 channel / 订阅，隔离每 session 的背压，根治洪泛。
• 重构：评估 codex app-server 是否支持 per-thread stream 订阅，从协议层消除共享 ring。

验收

• N 个项目并发跑高-delta review 时，单个 session 的事件量不会导致其它 session 被误标 Failed。
• 选定方案落地并有覆盖（并发洪泛场景测试或容量假设注释 + 测试锁定）。