docs(05): S7② 与 S3 的真机验收结清（S7② 通过；S3 在「在线冷启动进有内容次级会话」场景下否证）

S7②（通过）：补洞请求打在已摘除的会话上 ⇒ 404 ⇒ sessionGone；那句 8 秒的告知抓到（[33,378][1047,480]）；
select(主会话) 的副作用 POST /sessions/web/read 两轮都观测到。⚠️ 同时**修正我自己写的判据**：原先要求
「read 出现在 GET /sessions 之前」——实测顺序不确定（两条协程各起），该顺序判据不成立；真正该验的
「refresh 失败时也能回去」本轮没做。

S3（否证）：screenrecord + ffmpeg fps=8 抽帧 + 逐帧量两块区域的深色墨迹（不改生产代码）。时间线是
启动画面（新版图标）→ 「加载中…」 → 内容，**没有出现「还没有消息」空态**。局限：8fps 采样（<125ms
的闪烁会漏）、单场景、单 build，不写成「S3 不存在」。

方法论：别用墨迹的 x 宽度猜那是哪句话——我一开始据此误判，抽帧一看是「加载中…」。

devdocs/05-开发进度与交接.md

@@ -1582,3 +1582,25 @@ S2 我第一次测出「没生效」，差点去改代码——真因是**设备
 - **这一轮走到哪**：已**成功登录**（假后端收到 `POST /auth/login` + WS + 一串后续）、会话也已重建；但**进次级会话那一步没成**（dump 拿不到抽屉行坐标，盲点 `(146,595)` 也没落到行上）⇒ **S7② 仍未验**；S3 同样未动。
 - **一条不依赖 dump 的验证套路（下次直接用）**：**盲点 + 用假后端的请求流水判结果** —— 进次级会话的判据是 `POST /api/v1/sessions/<id>/read` 出现在流水里；进没进一看便知，比 dump 可靠得多（这也是 W49/W51 那两轮用过的路子）。
 - 收工时状态：`adb reverse` 已指回真后端（`tcp:80`/`tcp:10942` → 10942）；假后端已停；App 停在聊天页（拿的是假后端 token，会在真后端 401 上登出）。
+
+### 7. S7② 与 S3 的真机验收（2026-10-06 下午 · 补齐，**两条都结清**）
+
+**S7② —— 通过**
+- 造场景：App 停在次级会话（**进门判据 = `POST /api/v1/sessions/<id>/read`**，比 dump 可靠）→ 灌一条让它本端有内容（否则断线游标为空、逼不出补洞）→ 服务端 `POST /__control/forget` → **`POST /__control/ws-close` 真踢**（⚠️ 撤 `adb reverse` **不算**踢：已建立的连接不会断）。
+- **判据①（那条请求 404 ⇒ `sessionGone`）**：`14:22:28.957  GET /api/v1/sessions/…0002/messages?after=1791267700478` —— 补洞请求打在一个已被摘掉的会话上 ⇒ 服务端 404 `session_not_found`（该响应本轮单独核过）。
+- **判据②的界面一半（告知）**：**抓到了** —— `[33,378][1047,480] | 这个会话在服务端已经不存在了（可能已在别处删除），已切回主会话`。⚠️ 它只显示 **8 秒**（`SESSION_GONE_NOTICE_MILLIS = 8_000`）：前两次我都是事件后 ~50 秒才 dump，白跑两轮；**要抓它必须卡在 8 秒窗口内**（用「流水里出现补洞请求」当触发器，立即 dump）。
+- **判据②的「不依赖网络」一半**：`select(主会话)` 的副作用 `POST /api/v1/sessions/web/read` 两轮都观测到（`14:18:56.464` / `14:22:29.404`）。
+  ⚠️ **但要修正我自己原来写的判据**：我要求「`read` 出现在 `GET /sessions` **之前**」——实测**顺序不确定**（第一轮 `read` 在前 `.464`→`.480`；第三轮在后 `.040`→`.404`，两者是各起一条协程）。**那条顺序判据不成立，别再拿它当判据**；真正该验的是「**refresh 失败时也能回去**」那一档，本轮**没做**。
+- 顺带又验了 W51 判据第 1 条：同一个 VM 里 `sessionGone` 一旦为 true，**再重连也不再补拉**（第三轮 kick 后没有任何 `…0002/messages`）——「已知它没了就别再撞」生效。
+
+**S3 —— 否证（这个场景下没有空态闪烁）**
+- 手段（**不改生产代码**）：`adb shell screenrecord --time-limit 20 --bit-rate 6M /sdcard/s3.mp4` + 冷启动 → `ffmpeg -vf fps=8,scale=540:1170 -f rawvideo -pix_fmt rgb24` → 用一段 Python 逐帧量两块区域的**深色墨迹**（阈值 <120）：中央空态框（设备 x420-660 / y1180-1260）与第一条气泡框（x78-600 / y380-530）。
+- 时间线（8 fps，覆盖 0–11.4 s；抽帧确认过每一段的真身）：
+  | 时间 | 中央那块 | 气泡那块 | 抽帧确认是什么 |
+  |---|---|---|---|
+  | 0.1–4.6 s | 窄墨迹 `x540-588` | 0 | **启动画面**（就是**新版 App 图标**，顺带证明图标换上了） |
+  | 4.9–7.4 s | 宽墨迹 `x460-620` | 0 | **「加载中…」**（**不是**「还没有消息」） |
+  | 7.6 s 起 | 0 | 352 | 内容出现 |
+- **结论**：在线冷启动进「有内容的次级会话」时，屏幕是 **启动画面 → 「加载中…」 → 内容**，**没有出现空态** ⇒ **S3 在这个场景下否证**。
+- 口径与局限（别读成「S3 不存在」）：8 fps 采样（**<125 ms 的闪烁会漏**）、只测了这一个场景、只测了这一个 build。
+- 方法论一条：**别用「墨迹的 x 宽度」去猜那是哪一句话**——我一开始按宽度推断 4.9–7.4 s 是空态，抽帧一看是「加载中…」。**量到异常就抽那一帧看**，这才是收口。