fix(测试工具): 自检台账判据改为只看本次启动新增（修假绿）

接上一笔（FTP 凭据）之后，`@test --require-selftest-pass` 仍不可用——它其实是**三个 bug 叠
在一起**，这次一并收口。

**① 抓取失败被当成"设备干净"**：`_fetch_selftest_log()` 把"设备侧无此文件"（正常路径，
"仅故障才写"语义下干净设备本就没有该文件）和"连不上/登录被拒/FTP 故障"（结果**未知**）
都返回 `""`，调用方一律按"无记录 → PASS"处理。叠加上一笔修掉的匿名登录 530，这条门禁
**从写下那天起一次都没真正读到过那个文件**。现在 fetch 返回 `(路径, 状态)`，状态 ∈
{ok, absent, error}，三者分开判。

**② 判据本身判不了"一次启动"**：`/log/selftest.log` 是 **512 条环形累计历史**（设计文档
§4.2 容量表），而旧判据是"文件非空即 FAIL"——在任何做过故障注入或长跑的设备上**永远不
可能 PASS**。本次实机抓到的 29 条记录，时间戳全是 2026-10-10 ~ 10-14，没有一条来自本次。
新判据 `--selftest-scope this-run`（默认）：**烧录之前**先取基线，启动后再取一次，只把
"基线最后一条之后"的记录交给判定（差集落成临时副本，命名落在 `selftest_log_*.log` 里，
才会被 `--keep-out` 的保留规则收走）。

**③ 取基线本身会污染本次启动日志**（我这次实测踩到的）：抓基线是一次真实 FTP 会话——
设备把 `USER/PASS/RETR` 打到串口上，客户端退出时还多打一行 `[ERR] [FTP] error reading
next command`。放在 `open/clear`（采集武装）之后，这些行就落进本次启动日志：Forbidden
`[ERR]` 命中 → 本次 FAIL，开机耗时从 612 ms 被拉到 **7997 ms**。所以基线固定在 open 之前，
并把这条写进文档当规避口径。

**判定表**（`docs/测试说明/自动化测试流程.md` §自检结果判定整段重写）：无此文件=PASS；
本次无新增=PASS；本次有新增=FAIL；连不上/登录被拒/FTP 故障=**FAIL**；既无 `device_ip`
又无 `--selftest-log`=**FAIL**（要求判定却没有数据源，不能再"视为无记录"）；基线最后一条
被 512 条环覆盖（更新量 ≥ 环容）= **FAIL**（不拿"看不到"当"没有"）。后四种"判不了"由调用
方在 `verify()` 之后强制收口成 RC=1——否则标记全中就把"没判"读成"判过了、没问题"。

`--selftest-scope all` 保留旧的累计口径（审计 / 第一次建基线用）；给了 `--selftest-log`
（本地副本）就没有基线可比 → 自动降级为 all 并打印一行说明；FTP 凭据 `--ftp-user`/
`--ftp-pass`（config `ftp_user`/`ftp_pass`，默认出厂 admin/admin）。退出码 1 的含义、
`verify_log.py` 的语义条目、SKILL.md 参数表（+2 行）、config.example.json（+3 键）同步。

**真机三跑，三条路径各自验过**：
· 默认 this-run + `--device-ip` → **PASS / RC=0**：`基线 29 条 → 台账不变`、boot banner ×1、
  `net init: OK` **612 ms**（证明污染已消除）、Forbidden 零命中。
· `--selftest-scope all` → **FAIL / RC=1**：`29 fault record(s)`（累计口径仍可用）。
· 不给 `--device-ip` → **FAIL / RC=1**：`verify_log` 那侧显示 `no fault record → PASS`，
  调用方收口为 `RUN_TEST_VERDICT: FAIL —— 自检台账判定未能执行`（正是要的行为）。

门禁：`py_compile`（run_boot_test + verify_log）通过；`check_doc_links.py --all
--sections-strict` 146 文档 0 问题；`check_ids.py --strict` 增量拦截通过（可判定 82.82%，
在地板之上）；6 个文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无行尾空格。

**仍待办（本笔未做）**：设备侧"FTP 客户端中途退出"按 ERROR 级打日志（要不要降级）；lftpd
的 LIST 传完回 550 而非 226；设备 `/` 残留约 24 个旧探针文件；`MDK-ARM/` 下 4 个一次性
探针脚本仍写匿名。未推送。

docs/测试说明/自动化测试流程.md

@@ -51,10 +51,31 @@
 ### 自检结果判定（S7，`--require-selftest-pass`）
 
 `run_boot_test.py` / `verify_log.py` 支持 `--require-selftest-pass`：除串口标记外，还判定设备侧自检结论
-（v1 只记故障、不记通过）——`selftest.log` **缺失 / 0 字节 → 无故障 → PASS**；任一 64B 定长记录
-（`filesize/64 > 0`）→ FAIL，并打印故障条目（时间戳 + 描述）便于定位。`run_boot_test.py` 未给本地副本时
-**自动经 FTP 抓取** `/log/selftest.log`（设备侧 450"文件不存在"按正常路径处理——"仅故障才写"语义下
-干净设备本就没有该文件）。判定对象（20 处自检描述串）见 `实机测试实施指南.md` §3.2。
+（v1 只记故障、不记通过）。判定对象（20 处自检描述串）见 `实机测试实施指南.md` §3.2。
+
+**判据默认只看「本次启动新增」**（`--selftest-scope this-run`，2026-10-22 改）。原因：
+`/log/selftest.log` 是 **512 条环形累计历史**，而旧判据是"文件非空即 FAIL"——用它判一次启动，
+在任何做过故障注入或长跑的设备上**永远不可能 PASS**（本仓台架实测：抓到的 29 条记录时间戳
+全是 2026-10-10 ~ 10-14 留下的，没有一条来自本次）。新流程 = 烧录**前**先经 FTP 取一次基线、
+启动后再取一次，只把"基线最后一条之后"的记录交给判定：
+
+| 情形 | 含义 | 判定 |
+|---|---|---|
+| 设备侧无此文件（450/550） | 台账干净（"仅故障才写"语义下本就可能不存在） | 无新增 → **PASS** |
+| 抓到文件、本次无新增 | 本次启动没产生故障 | **PASS** |
+| 抓到文件、本次有新增 | 本次启动有故障 | **FAIL**，只打印新增条目（落 `selftest_log_<时刻>_new.log`） |
+| 连不上 / 登录被拒 / FTP 故障 | 结果**未知** | **FAIL**——旧行为是 WARN 后当"无记录"放过，那就是假绿 |
+| 既没有 `device_ip` 也没有 `--selftest-log` | 要求判定却没有数据源 | **FAIL**（同上，不再 WARN 放行） |
+| 基线最后一条在台账里找不到 | 512 条环已覆盖基线（更新量 ≥ 环容），无法证明 | **FAIL**（不拿"看不到"当"没有"） |
+
+- ⚠ **采集窗口内不要跑 FTP**：设备会把每条 FTP 命令打到串口，客户端退出时还会多打一行
+  `[ERR] [FTP] error reading next command` —— 默认 Forbidden 含 `[ERR]`，于是**任何**人边跑 `@test`
+  边用 FileZilla 传文件，都会让本次莫名 FAIL（本次改造实测踩到：抓基线原先排在采集武装之后，
+  开机耗时被自己的 FTP 会话拉到 ~8 s 并命中 `[ERR]`）。基线抓取因此固定在 open/clear **之前**。
+- `--selftest-scope all` = 保留旧的累计口径（任一记录即 FAIL），用于**审计**或第一次建基线。
+- 给了 `--selftest-log`（本地副本）就没有基线可比 → 自动降级为累计口径并打印一行说明。
+- 抓基线同样要 FTP 凭据：`--ftp-user` / `--ftp-pass`（config `ftp_user` / `ftp_pass`，默认出厂
+  `admin`/`admin`）；设备**没有匿名通道** → `FTP_Test_Guide.md` §1。
 
 ### 默认开机标记（来自固件）
 
@@ -125,3 +146,4 @@
 | 2026-10-10 | **第二批：闭环补上"烧进去的是哪份镜像"与"跑的过程中有没有偷偷复位"**：① 固件身份戳——`App/app/app_main.c` 开机打印 `fw build: <__DATE__> <__TIME__>`，`run_boot_test.py` 从待烧 hex 里抠出该串追加成 Required 标记（旧镜像/错镜像此前所有固定标记照样全中）；② 烧录回读校验进闭环——`reset.bat` 新增 `cmp` 子命令（`-CmpFile` 全片比对），采集后自动跑，不一致 exit 2；实测 `-CmpFile` 连接时会复位目标，故必须排在采集之后；③ 启动锚点计数——`verify_log.py` 新增 `--max-boot-count`/`--boot-marker`/`--expect-reset-cause`，`reset cause:` 出现 0 次或 >1 次判 FAIL；④ 修 `--flash-cmd` 带参数时预检必 missing、以及 `cmd /c` 对含空格路径（本仓库目录名 `DTU Code`）的引号解析把回读假判成"芯片不一致"（改为直接 CreateProcess 跑 .bat）。真机验证：完整烧录闭环 PASS（含戳匹配 + `No difference found` + 锚点 x1）；伪造戳 → 其余标记全中仍 FAIL |
 | 2026-10-10 | **第三批：判定可读性 + 时序 + 采集卫生**：① Forbidden 命中逐行打印行号+内容（旧只报条数）；② boot_log 每行加 `[+Nms]` daemon 毫秒时基（`--raw-log` 关闭），据此量开机耗时（实测 `net init: OK` = **+537ms**；`--max-boot-ms` 默认 0 只报告）；③ `--require-order` 标记先后顺序校验（全中但失序此前不可见）；④ `--json` 结构化判定（退出码不变）；⑤ `--keep-out`（默认 20）清理 out 目录旧产物（本机曾堆到 31+7 份）；⑥ daemon 侧：无换行残行 64KB 封顶 + open/close/clear 会话边界丢弃残行 + 截头按行边界对齐（旧实现截出来的首行是半行）+ `open` 不带 `--dtr/--rts` 时保持现状、显式给则现场应用；⑦ `ports` 回 `configured_present`/`hint`，`status` 回 `rx_age_ms`。selftest 23/23、verify_log 离线回归 17/17、真机闭环 PASS |
 | 2026-10-11 | **身份戳覆盖测试宏**（N-31 复测时发现）：切 `test/board/test_config.h` 的套件宏后 `app_main.c` 未被重编，测试镜像与产品镜像顶着同一个 `fw build:` 戳 → 戳校验对"两种构建互换"失明（当时只有 `-CmpFile` 回读发现镜像不同）。修复：`app_main.c` `#include "test_config.h"`（头依赖 → 改宏必重编、戳必刷新）+ 戳串追加 ` suite=<TEST_SUITE_NAME> dstr=<on|off>`（`FW_BUILD_VARIANT`，戳内容本身区分构建）。实测：`20:36:11 suite=NONE dstr=off` ↔ `20:36:40 suite=CH395F dstr=on`；`@test` 闭环对新格式 PASS（脚本无需改动，戳按"标记后连续可打印 ASCII"抠取）。失败模式表补一行：戳命中但 `suite=` 与要跑的套件不符 = 烧了产品镜像 |
+| 2026-10-22 | **自检台账判据改为「只看本次启动新增」**（修两处叠出来的假绿）：① 抓取用的 FTP 登录还写着匿名，而设备自鉴权落地起就没有匿名通道 → 抓取**必然** 530 失败，旧实现又把"抓取失败"和"设备侧无此文件"都返回空、一律按"无记录 → PASS"处理 → `--require-selftest-pass` 从写下那天起没真正看过文件；② 就算抓到了，`/log/selftest.log` 是 512 条环形累计历史，"非空即 FAIL"在任何做过故障注入/长跑的设备上永远不可能 PASS（本仓台架实测 29 条记录全是 2026-10-10 ~ 10-14 留下的）。现在：烧录前取基线、启动后只判新增；抓取失败 / 无数据源 / 基线被环覆盖 **一律 FAIL**；`--selftest-scope all` 保留累计口径用于审计与首次建基线；FTP 凭据 `--ftp-user/--ftp-pass`（默认出厂 admin/admin）。凭据与判据两处都过真机：`this-run` → PASS（无新增）、`all` → FAIL（累计 29 条）、无 `device_ip` → FAIL（无数据源）。 |