ci: agui-bridge-sse DA-19a 的 30 秒固定预算在 runner 高负载下反复超时——今天撞三次，每次浪费一趟 CI

## 现象
`apps/api/tests/**/agui-bridge-sse.test.ts` 的 **DA-19a**（`reusing the CUSTOM-reported chat_thread_id on the next turn continues the SAME Chat thread`）以 `Test timed out in 30000ms` 失败，重跑即绿。

今天三次，**三个 PR 都物理上碰不到这个文件**：
- #3079（只改 `apps/web` 三个文件）
- #3117（D6 四层，另有 `EADDRINUSE` 那次）
- #3123（只改 `harness-verify.yml` 一行描述 + `playwright.chat-read.config.ts` 的 testMatch）

## 代价
每次撞掉一整趟 `gates-test` 分片（约 11 分钟）+ 一次人工分诊 + 一次重跑。今天 runner 已经紧张（#3091）。

## 判断
不是产品回归，是**固定 30 秒预算**遇上高负载 runner。同类形态记在 #2968。

## 修法（择一，需实测支撑）
- 该用例的等待改成**基于事件**而非固定超时（等 `chat_thread_id` 的 CUSTOM 帧到达，而不是等墙钟）；
- 或按本仓既有做法给这条用例单独放宽预算，但**必须写清为什么它天然比别的慢**，不要全局放宽（全局放宽会掩盖真回归）。

⚠ 反证要求：改完后构造「第二轮确实没有续上同一线程」的情形，该用例必须仍然红——不能因为放宽超时就变成恒真门（本仓今天刚修过一个恒真门 #3122）。

Begin with apps/api/tests/**/agui-bridge-sse.test.ts and the DA-19a test, “reusing the CUSTOM-reported chat_thread_id on the next turn continues the SAME Chat thread”; run it repeatedly to observe the timeout. Trace the existing wait and repository patterns for per-test budgets, then verify that a second turn that does not reuse the same thread still fails. Done means the test remains reliable under runner load without masking that regression.

Written by the indexing model from the issue text.