ci(gates): 记下 test-coverage 自触发的实测语义（改触发面由旧配置管辖）

接线时遇到一个说不通的现象：把自触发写进 files: 之后，那次提交里 test-coverage 仍然
Skipped；而我用 --files 与 staged 两种方式手工跑都会实跑。今天补做对照才定位：
同一批输出里 bsp-err 也 Skipped，而它的 files: 从很早就含 ^\.pre-commit-config\.yaml$。
两次现象一致指向同一条规则——**修改钩子配置的那次提交，按"修改前"的配置求值**。

这条对门禁的自洽性是好事：
- 想**拆掉**自触发（把 files: 里的本文件删掉）：这次提交仍受旧模式管辖，钩子照跑，拆不掉；
- 想**加**触发面：要等下一次提交才生效，也就是加固会迟到一步、拆除不会漏网。

顺带说明：上一轮我"还原诊断探针"时命令顺序写错（先 git reset 再 git checkout --，
后者又从暂存区把那版恢复回来），弄出一条 # probe 残留在工作区；把它删掉后文件与
HEAD 完全一致，所以刚才那次 git commit 其实是 nothing to commit（不是被钩子拦的）。
现工作区已核实与 HEAD 一致、无残留。

.pre-commit-config.yaml

@@ -608,6 +608,9 @@ repos:
       #    口径 / 分母 / 基线 / 盲区详解都在 docs/测试说明/主机单测覆盖率口径.md，本处只留接线事实。
       #    触发面**含门禁自身**（.pre-commit-config.yaml）：不带自身就等于谁改坏这根闸的 files:
       #    模式，它就再也不跑且无人察觉（同 lv-conf-sync / bsp-err 的既有做法）。
+      #    实测语义（2026-10-24，两次真提交对照出来的）：**改这行 files: 的那次提交，由改之前
+      #    的配置管辖**——所以"删掉自触发"这一刀会被旧配置拦住（旧模式仍含本文件，钩子照跑），
+      #    而新加的模式要等下一次提交才生效。方向正好是对的：加固会迟到一步，拆除不会漏网。
       - id: test-coverage
         name: 主机单测覆盖率（增量拦截：已覆盖行只增不减）
         entry: python scripts/check_test_coverage.py