fix(worker): codex 有结构化 429 信号后关闭其扫屏限流误判

[DeepColds]

问题

codex 会话经常弹出「当前已达到 Codex 使用限额，请在 5-10 min 后再试」，但账号/LLM 实际并没有被限流。

根因在扫屏检测 detectCliUsageLimit：它每帧扫终端画面文本，只要出现 status: 429 / 429 Too Many Requests / exceeded retry limit 就按硬性 429 处理，并套一个 5-10 min 的兜底冷却（hardRateLimitFallbackTime，label 恒为「5-10 min」，非模型服务返回）。于是把 agent 的回答内容、工具输出、上下文里出现的 429 字样 误当成「LLM 请求被限流」。

典型触发：在 codex 里排查 429 相关问题时，屏幕上的 429 字样触发自身误报；而且冷却期内、或上下文里持续包含 429 字样时继续对话会反复触发（classify() 扫的是当前屏幕快照，不是本次请求结果）。

根因分析

不是「codex 缺结构化限流信号」。worker 已有 maybeEmitCodexStructuredRateLimit：它读 rollout 的 codex_rate_limited 终态（isCodexRateLimitEvent）并 emit limited —— 这是「请求真的返回 429」的机器信号。

问题是没有据此关掉扫屏：两条路径并存，扫屏仍会误报。而 isStructuredRateLimitAuthoritative 此前只 gate 在 claudeDataDir，只有 Claude 家族借结构化信号关掉了扫屏。

改动

• types.ts：新增适配器能力位 emitsStructuredRateLimit，表示「本适配器会从 transcript 的机器信号 emit 结构化 limited」。
• codex.ts：置 emitsStructuredRateLimit: true（结构化 emit 仅在 structuredBridgeIsCodex() 分支运行，其它 codexBridgeQueue CLI 没有）。
• cli-usage-limit.ts：isStructuredRateLimitAuthoritative 同时认 claudeDataDir 与 emitsStructuredRateLimit。
• 同步更新 worker.ts / pi.ts 中已过期的相关注释。

效果：codex 与 Claude 家族一致，以结构化 429 为唯一权威、关掉扫屏 rate 误判；usage（额度类，无结构化等价物）仍走扫屏，不变。

影响面

• 不动其它 codexBridgeQueue CLI：grok / traex / pi / hermes / mtr / cursor 均无结构化 emit，未置该位，继续扫屏 —— 真实 429 的 backoff 与 Dashboard「需要你」信号不受影响。谓词仍不 gate 在 reliableTurnTerminal（否则会误伤这批）。
• Claude 家族路径不变（仍走 claudeDataDir）。

验证

• pnpm build 通过。
• 更新/新增单测：断言 codex 现为 authoritative、grok/traex/pi 仍非、null/undefined/空对象为 false。
• 相关测试全绿：cli-usage-limit / cli-adapters / cli-selection / codex-effort-wiring / codex-adapter-history-ownership / write-input，共 599 例通过。

🤖 Generated with Claude Code