flaky(chat-read): #2293 串行锁生效后仍有残余抖动——两轮安静复跑 4/66 与 2/66 红且交集为空，H3 硬门持续钉死 V-D/V-P

## 现象

实测 SHA `2ddc3e0df28562eb5ec5e020a857ad4509f6289b`（= origin/main HEAD，含 #2309 修 #2307），
工作树 `git status --porcelain` 为空，独立 worktree（`./init.sh` exit 0）。

rev-uiux 为 CLR 硬门 H3 跑 `pnpm run verify:chat-read` 两轮**独立、机器安静、无并发**：

| 轮 | 起跑 load1 | 结果 | 失败用例 |
|---|---|---|---|
| 1 | 4.27 | 4 failed / 62 passed (9.2m) | `chat-read.spec.ts:413`、`copilotkit-v2-attachments.spec.ts:55`、`copilotkit-v2-message-actions.spec.ts:71`、`copilotkit-v2-skill-mount.spec.ts:140` |
| 2 | 1.81 | 2 failed / 64 passed (5.5m) | `chat-diagram-save-reopen-roundtrip.spec.ts:223`、`copilotkit-v2-hitl.spec.ts:236` |

**两轮失败集合交集 = ∅**，6 个用例互不重复。

## 为什么这次不能再归给「机器并发」

#2258 的裁决是「修取证环境」而不是「改判据」，PR #2293 加了重 e2e 准入串行锁。本轮实测该锁**确实生效**：
两轮日志均为 `[stack-admission] running=0/2`、`等待重e2e互斥锁：0s`，取证期间 `ps aux | grep playwright` 为 0 条其它进程。
所以「另一个会话在同机跑 playwright」这个解释**已被排除**，但抖动仍在，量级约每轮 3%–6%。

## 失败长相（全部是时序/DOM 竞态，不是内容断言不符）

- `chat-read.spec.ts:418` — `toHaveURL(/\/projects$/)` 收到 `/login`，30s 超时（登录后没跳转）
- `chat-diagram-save-reopen-roundtrip.spec.ts:331` — `locator.scrollIntoViewIfNeeded: Element is not attached to the DOM`
- `copilotkit-v2-hitl.spec.ts:241` — `getByTestId('copilotkit-v2-hitl-reject')` 30s 内 not found
- `copilotkit-v2-message-actions.spec.ts:62` — `chat-task-workbench-capability-picker` 20s 内 not found
- `copilotkit-v2-attachments.spec.ts:109` — `chat-attachment-list` 期望 0 收到 1（发送后 composer 待发附件条没清空）
- `copilotkit-v2-skill-mount.spec.ts:169` — `waitForResponse` POST `/skill-mounts` 180s 超时

其中 `copilotkit-v2-attachments.spec.ts:109` 长相是**内容断言不符**而非超时，值得单独看一眼是不是真 bug。

## 影响

CLR 硬门 H3 的字面判据是「`verify:base` 与 `verify:chat-read` 都绿」。因为没绿，V-D / V-P 本轮仍记 0，
**逐维观测分被硬门吃掉**（非计分观测：V-D 6/10、V-P 10/10，见 `.harness/state/core-loop-readiness.json` 本轮记录）。
这已经是连续第 N 轮「界面本身没问题、分数卡在 H3」。

## 未做到的取证（如实交代）

本想把 6 个用例挑出来单跑若干轮判定是否确定性，两次尝试都在起栈阶段挂掉：
`failed to resolve reference "docker.io/library/redis:7-alpine": context deadline exceeded`
（`curl https://registry-1.docker.io/v2/` 返回 000，本机到 docker registry 当时不可达；
`redis:7-alpine` 本地有缓存但 compose 仍去 registry 校验）。所以**「这 6 条是抖动」是从
「两轮交集为空 + 失败长相全是超时/竞态」推的，不是逐条复跑证实的**。

## 请裁决 / 请修

1. 优先：逐条定位这 6 个用例的竞态根因（不许加 `retries`、不许放宽超时值——这是 #2283 那轮已经写明的纪律）。
2. 顺带：compose 在本地已有镜像时不应硬依赖 registry 可达（`pull_policy: missing` 之类），
否则网络一抖整条取证通路就断，且长相是「测试失败」而不是「网络失败」。

/cc rev-uiux（本 issue 由评分员在取证中开出，评分员不改产品代码）

Start by inspecting the six named Playwright specs and their failure locations, then run `pnpm run verify:chat-read` under the serialized e2e lock. Compare the reported failures with their test setup and trace the timing or DOM races; do not add retries or loosen timeouts. The issue also flags Compose image resolution for `redis:7-alpine`; completion means identifying and fixing the race causes and avoiding unnecessary registry dependence when the image is cached.

Written by the indexing model from the issue text.