chore(台账): RAM 基线、体积凭证与覆盖率基线随 22:52 构建回填

三个基线文件与一篇内存文档表格同步到同一事实源（MDK-ARM 下 .map，mtime 2026-10-26
22:52:12；.map/.htm 按约定不入库，故把身份写进正文）：
· Code 231,712 B / RO 25,560 B / RW 1,504 B / ZI 136,216 B
· ER_IROM1 257,272 B（24.5%）、RW_IRAM1 80,312 B（61.3%）、RW_CCM 57,376 B（87.9%）、
  Flash 合计 258,792 B（24.7%）
· scripts/size_attestation.json 记录索引指纹 06808c35e47b…（1430 个文件），把「这份
  体积数出自哪一份工作树状态」变成机器凭证，而不是口头

覆盖率基线登记两条 [NOTE]（此前挂着不登记就是在攒债）：
· Drivers/BSP/UI/ui_data.c 65 → 316 行——账在 Lead：task-1 那笔改了装配层却没回填
  基线，此后每次提交都打印同一条 NOTE；一条长期存在的 NOTE 等于没有 NOTE。
· App/protocol/iec104/iec104_comm.c 36/36 行——task-8 搬家新增模块，作者已自测，
  登记归共享台账（我串行改，避免两个道同改一份门禁账）。
当前口径：line 6854/7626（89.9%）、func 505/542（93.2%）、suites 40/40、
tested_files 45、untested_files 142。

为什么这一笔能走真钩子：这是今天第一个静默窗口——四条道全部 PAUSED，全量
pre-commit 实跑（改写型钩子在没人写盘时才安全），因此这一笔不需要任何 --no-verify
例外。今天前三次 --no-verify 共放过三类真问题（5 条 CODE-RULE-17、2 个缺尾换行加
1 个漏提文件、共享尾段 +80 B 把 iec104Task 压到 ISR 底线之下），根因都是「抢跑时
没跑等价门禁」；task-37 把那张自查表写进了 pre-commit 使用说明，这一笔是还清的债。

仍然挂着的一条闸线：id-check 不可判定引用 1,162 处 / 上限 1,166，余量只剩 4。
主要吃进者是今天 UI 那笔（三页与其 68 条文本断言的注释引用），账在 Lead。
清账之前任何人新增编号都可能直接撞闸——已记进 task-34：要么把裸 TC 引用改成指向
属主登记处的写法让 und 掉头，要么把余量当硬约束写进协作口径。

docs/内存管理/RAM使用分析与优化方案.md

@@ -47,10 +47,10 @@ dhara 失败类 +84；RO 另 +208，全是该失败类名表）→ `ER_IROM1`
 <!-- MEM_SNAPSHOT:BEGIN generated by scripts/check_mem_numbers.py -->
 | 区域 | 用量 | 容量 | 占比 |
 |---|---|---|---|
-| ER_IROM1 | 253,220 B (247.29 KB) | 1,048,576 B (1024 KB) | 24.1% |
-| RW_IRAM1 | 79,992 B (78.12 KB) | 131,072 B (128 KB) | 61.0% |
+| ER_IROM1 | 257,272 B (251.24 KB) | 1,048,576 B (1024 KB) | 24.5% |
+| RW_IRAM1 | 80,312 B (78.43 KB) | 131,072 B (128 KB) | 61.3% |
 | RW_CCM | 57,376 B (56.03 KB) | 65,280 B (64 KB) | 87.9% |
-| **Flash (ROM 合计)** | **254,660 B (248.7 KB)** | 1,048,576 B (1024 KB) | **24.3%** |
+| **Flash (ROM 合计)** | **258,792 B (252.7 KB)** | 1,048,576 B (1024 KB) | **24.7%** |
 <!-- MEM_SNAPSHOT:END -->
 
 各区的容量与常量来源：