fix(worker): 避免 TraeX 首条消息被启动页吞掉

[xiongz-c]

背景 / 动机

TraeX 新会话 fresh start 时可能先停在 trust/advisory 启动页，真实输入框的 readyPattern 晚于 worker 的 15s first-prompt timeout。旧逻辑会在 timeout 后直接 flush 队列里的首条消息，导致首条用户指令可能写入非输入框状态并被吞掉。

改动

• 在 adapter 上新增 deferFirstPromptTimeoutUntilReady 能力位，TraeX 打开该能力，worker 不再硬编码 cliId === 'traex'。
• 将 15s first-prompt timeout 保留为软兜底：普通 CLI 仍按原逻辑释放队列；TraeX 若还没出现 readyPattern，则继续等待真实输入框。
• 为 TraeX 增加 90s 硬兜底：readyPattern 一直没出现时打 warn 日志并强制释放队列，避免首条消息永久卡死。
• 恢复非 TraeX 的 busy-pattern 语义：先 awaitingFirstPrompt=false + markNewTurn() 解锁启动期，再执行 busy probe，避免扩大行为变化。

测试覆盖

• 新增 shouldReleaseFirstPromptTimeout 行为测试，覆盖普通 CLI 15s 释放、TraeX 软超时继续等待、90s 硬超时释放、无 readyPattern 不延迟。
• 调整 worker source guard，确认 first-prompt timeout 的 busy probe 发生在启动期解锁之后。

验证

• pnpm vitest run test/input-gate.test.ts test/worker-pipe-initial-screen-order.test.ts
• pnpm build
• git diff --check

影响范围

影响范围收窄在 opt-in adapter 能力位。当前只有 TraeX 打开该能力；其他 CLI 的 15s timeout fallback 行为保持不变。TraeX 最多等待 90s，之后会强制释放首条消息并留下 warn 日志。

[xiongz-c]

为了避免扩大影响面写死了traex，目前只看到traex有可能启动较慢，如果需要做成通用的可以放开这个限制