main 上 chat-read 红一条核心路径：多轮对话第二轮引用第一轮输入 + 双 run 持久化

## 现象

main（`0d4f8decf`）的 `harness-verify` run **34446723312**，`chat-read` 车道：

```
✘ 4 [chat-read] › e2e/agent-chat-core-paths.spec.ts:104:5
多轮对话：第二轮在同一线程引用第一轮输入，并分别持久化两个 run (53.7s)
1 failed | 116 passed (25.9m)
```

这是**核心路径**——用户视角就是「第二轮记不记得第一轮」。

## 要先回答的问题（写成可证伪形式，先写后判）

- **假说 A —— #3047 那族的顺序相关红**。该车道 96+ 条 spec 无逐测试隔离，每趟约 25% 红且**失败集互不相同**。
- 若成立 ⇒ 单独跑该 spec 应稳定绿；整条车道重跑，失败集会变（这条不再是它）。
- **假说 B —— 今天某次合并引入的真回归**。今天入 main 的有 #3295、#3299、#3300、#3305、#3306、#3307、#3315、#3323、#3324、#3326、#3327、#3328、#3329（外加别的会话合的 #3325）。多条动过 chat 前端、审批链路、回环替身。
- 若成立 ⇒ 单独跑该 spec 稳定红；在某个提交之前的树上稳定绿，之后稳定红（二分可定位）。
- **假说 C —— 环境红**（端口占用、栈争用、依赖缺失）。
- 若成立 ⇒ 失败签名里会有 `EADDRINUSE` / 连接错误 / **零测试计数**之类，而不是业务断言。**本例是业务断言失败（第 104 行），所以 C 的优先级最低**，但仍需排除。

**判别方法要求**：不要只重跑一次就下结论（「绿了 ⇒ 是 flake」是最容易自欺的推断）。至少：① 单独跑该 spec 若干次；② 若怀疑 B，在候选提交前后各跑一次做对照，**声明实测 SHA**。

## 已知的坑，别踩

- **`chat-read` 只在非 PR 事件上跑**（`github.event_name != 'pull_request'`），所以它在任何 PR 上都是 `skipping`——`skipping` 不是通过。要在分支上验证得用 `workflow_dispatch`。
- **车道去重会回放旧判决**：job 红但**测试计数为 0** ⇒ 根本没跑。判定前先看计数。
- 用 `fresh_run=true` 避开去重回放。
- 主 checkout `/Users/shenyanbin/Documents/workspacex` 停在旧提交，在它上面 grep 会读到过期代码；取证以 `origin/main` 为准。

## 要求

- 若判定 B（真回归）：定位到具体提交，建 PR 修，**配三步反证**（造出缺陷形状 → 断言变红并贴真实输出 → 撤掉 → 恢复绿）。只贴绿不算数。
- 若判定 A：在 #3047 上补一条评论，把本次失败集与历史几趟的对照写进去（这是「失败集互不相同」的又一条证据），不要顺手改。
- 无论哪种，都要说明**另外两个假说为什么被排除**。

Start with e2e/agent-chat-core-paths.spec.ts at line 104 and inspect the harness-verify run and test count on origin/main. Run the named spec repeatedly through workflow_dispatch with fresh_run=true, then compare candidate commit SHAs before and after any suspected regression. Done means identifying A, B, or C with the required evidence, and either commenting on #3047 or preparing a regression fix with the three-step countercheck.

Written by the indexing model from the issue text.