chore(编号): 存量编号全量转语义短语，门禁识别面与语料同批重打

登记簿、文档与代码注释里的存量字母加数字编号（N-x / S-x / T-x / E-x / A-x / 卡号）
一律改写为语义短语，净删 2,028 处引用；删除基线与待确认、并行分道方案、排期详述、
采集保护收尾 4 篇（内容已并入 docs/任务规划/README 与登记簿）。

门禁机器与三张账同批重打：check_ids.py 新增变更记录行豁免与第二根护栏
undecidable_total_ceiling；check_test_traceability.py 只加 stdout/stderr UTF-8
reconfigure（TC_RE 未动）；check_cubemx_survival.py 的 --write 固定 newline=LF；
id_registry / id_aliases（+19 条 retired-to-phrase）/ id_known_backlog 重打。

test/ 56 个文件同步 TC 标签语义化，其中 18 个 TU 改了 CHECK / printf 里的标签文字，
是本批唯一改变构建产物的文件集合。

为什么合成一笔、不拆四笔（实测撞闸，非偏好）：pre-commit 跑钩子前会 stash 未 staged
部分，拆开后中间提交必然是「新规则 + 旧语料」——实跑可判定 85.15% < 基线 86.00%、
不可判定 1,453 > 上限 1,166，编号门禁直接拦下。编号识别面与它描述的语料只能同码移动。

实跑基线（工作区全量）：754 文件 / 8,230 处编号字面量 / 可判定 7,079 = 86.01%
（基线 86.0%，容差 0.1pp）/ 不可判定绝对数 1,151（上限 1,166）/ 校验 1-6 错误级 0 /
告警 = 悬空 2（App/algo/freq.c 的 S2，属 §4.4 同号不同义）+ 孤儿 50。

基线从 84.0 抬到 86.0 的理由见 docs/门禁说明/id-check.md §7.6：本批真删了 2,028 处
引用，可判定面随真实内容上升，不是把分母做小。同批新增排除 docs/硬件平台/ 语料，使
识别面少 264 处——芯片手册位号与网表料号不属编号空间（registry 有 excluded_paths_note）。

⚠ 余量只剩 0.11pp（约 10 处）与绝对数 15 处：把「可判定的引用」改成散文会立刻撞第二
根护栏。另遗留一项：id_aliases 里 retired 的 N / S / T / A 别名没有 scope（U1~U5 有），
今后有人新写一个 A-4，校验 3 不会响，只能靠人，建议下批补 scope。

固件不变证据：115 个 .c/.h 剥注释并归一字符串后与 HEAD 逐字节全等，残留代码差异 0；
App / Src / Drivers 的字符串字面量零改动。@build 0 错误 0 警告；40/40 主机套件、2,889
断言全通过；覆盖率 line 89.2% / func 92.6%；pre-commit 48 钩子 --all-files 全绿；
check_doc_links --all 通过（176 文档，章节引用无法判定 0）；逐字节卫生核过：14 个带
BOM 文件与 HEAD 一致、0 个 CR、0 个 U+FFFD，字符串字面量纯 ASCII。

.cubemx_survival_baseline.json 的 watchdog-module 哈希 56bf27 变 2bb051 属合法：
Src/freertos.c 的 USER CODE 区内只有注释文字随编号改写，代码未变。

同批带上体积同码凭证与 RAM 台账行（@build 之后盖戳）：RW_IRAM1 79,008 B / 60.3%，
RW_CCM 57,376 B / 87.9%，阈值 92%。

test/host/cfg_file_store_mcu/cfg_file_store_mcu_test.c

@@ -3,7 +3,7 @@
  * 模块功能：在 PC 上离线验证 App/cfg/cfg_file_store_mcu.c 的五个卷操作 + 三个堆操作：
  *             cfg_store_read / cfg_store_write_atomic / cfg_store_stat /
  *             cfg_store_remove / 两个路径 getter / alloc-free-heap_free
- *           重心放在**原子写**与它的 v1.2 修复（E-01）上：本 FatFs 移植的 f_rename
+ *           重心放在**原子写**与它的 v1.2 修复上：本 FatFs 移植的 f_rename
  *           对已存在目标返回 FR_EXIST、**不覆盖**，所以"覆盖写"必须先 f_unlink 目标
  *           再 f_rename——少了这一步，一切非首启保存（UI 改配置、模板重建）静默失败，
  *           而模拟器后端（POSIX rename 覆盖语义）照不出来。
@@ -11,12 +11,12 @@
  * 被测对象：真实源文件 App/cfg/cfg_file_store_mcu.c（#include 原样纳入）。
  *           假件与桩：
  *             test/host/common/fatfs_fake.{h,c} —— 假 FatFs 内存卷（真实 ff.h 声明；
- *               它的 f_rename **如实返回 FR_EXIST**，正是 E-01 的那颗雷）
+ *               它的 f_rename **如实返回 FR_EXIST**，正是原子写那颗雷）
  *             stub/FreeRTOS.h —— 三个分配器原型（签名逐条对齐 portable.h:163/164/166）
  *             假卷锁 / 假堆（可注入分配失败）写在本文件里
  *
  * 为什么要主机侧单测（而不是只靠台架）：
- *   1. **E-01 原子写**：unlink→rename 这个非原子窗口是"掉电时配置暂失、开机按首启
+ *   1. **原子写**：unlink→rename 这个非原子窗口是"掉电时配置暂失、开机按首启
  *      重建工厂模板"的有意取舍。任何一次"顺手优化"（比如给 rename 加覆盖、或把
  *      unlink 挪到 rename 之后）都会让配置保存静默失败或留下脏 TMP，而这在 POSIX
  *      后端上完全看不出来。→ 假卷把 FR_EXIST 原样喂进来。
@@ -44,7 +44,7 @@
  *   —— 原子写 ——
  *   TC-CFGFST-010 首启写：TMP 建 -> 写 -> unlink(目标,FR_NO_FILE 容忍) -> rename
  *   TC-CFGFST-011 **覆盖写必须先 unlink 目标**：假卷 rename 对已存在目标返 FR_EXIST，
- *                 少了 unlink 就是 -1 且旧内容原封不动（E-01 的直接复现）
+ *                 少了 unlink 就是 -1 且旧内容原封不动（原子写缺陷的直接复现）
  *   TC-CFGFST-012 rename 失败 -> -1 + TMP 清理 + 目标内容保持不动
  *   TC-CFGFST-013 TMP 打开失败 -> -1、零 write、release
  *   TC-CFGFST-014 写短（FR_OK + 字节数不足）-> -1 + TMP 被删 + 目标原内容不动
@@ -326,7 +326,7 @@ static void tc_write_atomic(void)
     size_t n;
     int ok;
 
-    printf("-- TC-CFGFST-010..020 atomic write (core of E-01) --\n");
+    printf("-- TC-CFGFST-010..020 atomic write (core regression) --\n");
 
     /* 010 首启写（目标不存在） */
     reset_all();
@@ -339,7 +339,7 @@ static void tc_write_atomic(void)
           && (s_lock_releases == 1) && (s_lock_seq_err == 0),
           "TC-CFGFST-010 first write: TMP -> rename -> target 2 bytes, no TMP left behind");
 
-    /* 011 覆盖写：假卷的 f_rename 对已存在目标返回 FR_EXIST —— 这就是 E-01 */
+    /* 011 覆盖写：假卷的 f_rename 对已存在目标返回 FR_EXIST —— 这就是原子写的雷 */
     reset_all();
     ok = (cfg_store_write_atomic(P_CFG, (const uint8_t *)"old-content", 11u) == 0);
     {
@@ -349,7 +349,7 @@ static void tc_write_atomic(void)
               && (ff_fake_fetch(P_CFG, buf, 0u, sizeof(buf)) == 3u)
               && (memcmp(buf, "new", 3u) == 0)
               && (g_ff_obs.calls[FF_FAKE_OP_UNLINK] == unlinks_before + 1),
-              "TC-CFGFST-011 overwrite: unlink target exactly once then rename -> new content lands (E-01)");
+              "TC-CFGFST-011 overwrite: unlink target exactly once then rename -> new content lands (atomic-write trap)");
     }
     /* 同一条的"反面"：直接 rename 到已存在目标必败（证明上一步的 unlink 不是多余的） */
     {

test/host/cfg_file_store_mcu/run_unit_test.py

@@ -5,12 +5,12 @@ r"""配置存储后端（cfg_file_store_mcu）的主机侧单元测试运行器
 做什么：
     用本机 MSVC 编译 test/host/cfg_file_store_mcu/cfg_file_store_mcu_test.c（以
     #include 纳入**生产源** App/cfg/cfg_file_store_mcu.c，并纳入共享假卷
-    test/host/common/fatfs_fake.c），在 PC 上离线跑读、原子写（E-01 的
+    test/host/common/fatfs_fake.c），在 PC 上离线跑读、原子写（
     unlink->rename 全链）、状态令牌、删除、路径 8.3 合规、假堆分配，失败即非 0 退出。
     工具链与判定委托 test/host/common/unit_test_harness.py。
 
 为什么要主机侧单测（而不是只用台架）：
-    1. **E-01 原子写**：本仓 FatFs 移植的 f_rename 对**已存在目标返回 FR_EXIST、不
+    1. **原子写**：本仓 FatFs 移植的 f_rename 对**已存在目标返回 FR_EXIST、不
        覆盖**，所以覆盖写必须先 unlink 目标。模拟器后端（POSIX rename 覆盖语义）
        永远照不出这一条 → 曾经"一切非首启保存静默失败"。假卷按真实 ff.c 返回
        FR_EXIST，把这条做成必然失败的断言。