docs(05): S7②/S3 第二轮受阻记录 —— 模拟器劣化与主机被占、不依赖 dump 的验证套路、收工状态

为什么：这一轮 S7② 仍未验（进次级会话那一步没成），但花掉的时间都是环境问题而非代码问题，
必须把「先看主机在跑什么」「盲点 + 用服务端流水判结果」这两条写下来，下一轮别再重摸。

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

@@ -1575,3 +1575,10 @@ S2 我第一次测出「没生效」，差点去改代码——真因是**设备
 - **判据（两条）**：① 客户端发出那条请求并拿到 404 ⇒ `sessionGone` 置位；② 界面上出现那句告知，且 `POST /api/v1/sessions/web/read`（`select(主会话)` 的副作用）**在 `GET /sessions` 之前**出现 —— 后者才是 W51 那句「出路不依赖网络」的证据。
 - **我卡在哪**：登录表单被前几轮实验搞乱了（地址栏里还留着 W48 那次的坏值 `http://loclocalhostalhost/`，用户名/密码/展开态彼此错位），`input text` 落不进目标字段；且 `uiautomator dump` 会**返回陈旧缓存**（同一次交互前后两张 dump 的地址栏展开态互相矛盾）。这个会话里我为此烧了好几轮，按「别把预算烧在仪表上」停手。
 - **下次的干净起手**：`adb shell pm clear top.yeij.cyrene` → 登录页只填**纯字母**的 `localhost`（`normalizeBaseUrl` 会补 `http://`，见 `07` §2 第 1 条）+ 任意 ASCII 账号密码 → 每填一个字段**都 dump 一次确认值真的进去了**（别信「刚才填过」），再点登录。
+
+### 6. S7②/S3 第二轮再次受阻（2026-10-06 下午，写给下一个我）
+- **模拟器跑了约 6 小时后劣化**：`screencap` 返 **0 字节**、`uiautomator dump` **大面积失败或返陈旧缓存**（同一次交互前后两张 dump 的地址栏展开态互相矛盾）。已**重启模拟器**（run10；`boot=1` 约 170 秒；重启后 `adb root` 与两条 `adb reverse` 都要重新加）。
+- **重启后仍不稳**：设备侧 `system_server` 111% CPU、sensors HAL 73%、Google 全家桶在抢；而**主机上当时也有负载**（`Get-Process` 里能看到 `cs2`、`msedgewebview2` 等）⇒ **大概率是主机被占，不是 App 的问题**。**以后遇到「adb 很慢 / 截图 0 字节 / dump 失败」先看主机在跑什么**，别先怀疑代码。
+- **这一轮走到哪**：已**成功登录**（假后端收到 `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 上登出）。