chat-read 车道：第一波并行 worker 稳定整批红（串行跑 19/19 通过）

## 现象

`chat-read` 车道在**第一波并行 worker** 上稳定地整批红，与被测代码无关。

只跑该车道的 8 个 spec 文件（Playwright 默认在本机取 5 个 worker，`fullyParallel: false` ⇒ 5 个文件同时开跑），**连续四轮**复现同一形状：第一波 5 条用例整整齐齐在 ~49–59s 全红，错误只有两种

- `getByTestId('chat-thread-')` element(s) not found —— 左栏线程列表始终是空的（页面其余部分正常：`copilotkit-v2-input` 在、侧栏文案「项目上下文，按对话权限可见」在、搜索框在，**既没有空态也没有 `copilotkit-v2-thread-list-error`**，就是一直没数据）
- 登录页停在 `/login`，页面上印着「登录服务暂时不可用，请稍后重试」

同一个 worker 的第二、三条用例随后全部通过。

## 决定性对照（同一份代码、同一批文件）

| 跑法 | 结果 |
| --- | --- |
| 默认（5 worker 并行） | 每轮第一波 5 条全红，整体 13–16 passed / 5–6 failed |
| `--workers=1` 串行 | **19 passed / 0 failed** |

串行那轮里，此前每轮必红的那 5 条耗时分别是 F65 **11.6s**、图片附件 **12.5s**、png 预览 **9.2s**、G2 画像 **29.5s**、键盘发消息 **5.3s** —— 不只是通过，而且只花了并行那轮（~49s 超时）的零头。

## 已排除的假设

「API 还没起完」**不是**根因：给 `chat-route-warmup.global-setup.ts` 补了一次真实鉴权读探测（等 `GET /chat/threads` 不再是连接层失败/5xx）之后又跑一轮，第一波仍然 5 条全红、形状逐字相同。该改动已按「没有反证支持的修法不留在树上」整段撤回。

## 为什么值得单独修

- 这不是只跑子集才有的问题：跑整条 91 条车道时第一波同样有 5 个文件同时开跑，只是后面 80 多条把比例稀释了，看起来像「偶发」。
- 它把一条本来能判「这次改动有没有坏东西」的车道，变成了每轮都要人工分辨「这条红是真的还是第一波」的车道——正是本仓对恒红门的既有判词（`lib/pr-queue.ts:116`：恒红的门比没有门更糟）。

## 建议排查方向

线程列表那一跳（`listWorkbenchThreads` → `GET /chat/projects/:id/threads`）在 5 个浏览器上下文同时打第一次时拿不到数据，且前端既不报错也不显示空态——先确认是服务端那一跳超时/被取消，还是 `copilotkit-v2-shell.tsx` 的 `loadThreads` 在 `AbortController` + StrictMode 双调用下把结果丢了。

## 相关

issue #2997（本 issue 的证据全部来自那轮迁移的实测）。

Reproduce the chat-read lane with the default five workers and with --workers=1, then inspect the threads request path from listWorkbenchThreads through GET /chat/projects/:id/threads. Read chat-route-warmup.global-setup.ts and copilotkit-v2-shell.tsx, focusing on loadThreads, AbortController, and StrictMode behavior. Done means the first parallel wave no longer fails and the lane passes consistently without hiding genuine errors.

Written by the indexing model from the issue text.