docs(问题记录): 删除项目审查与优化建议报告，结论并入模块文档与编号规范

用户裁定：该报告大部分内容已闭环，可删除；仍有价值的迁到合适文档。删前逐条核对，
确认绝大多数结论在仓内早已有权威副本（LV_DRAW_SW_COMPLEX / osFlagsNoClear / SPI 分频 8
/ 分层反向依赖存量基线等），只迁真正独有的四类内容：

1. 暂缓理由与重开条件（三条量化门槛）→ RAM 使用分析与优化方案 §4，并明确「本节是唯一
   权威」，其它文档只留指针；同时把 10 处指向报告 §5.3 的重开条件引用改指该节。
2. 2026-10-22「常驻 vs 动态」三项诊断（静态前五块 43,462 B = 58%；动态面只有 heap_4，
   故栈余量=CCM 余量；栈深主因是日志/配置写链）→ 同文档 §2.5。
3. `_fp_digits` 1,018 B 删不掉的机理与 F-6 根因修法（Q10 宏改单精度，−332 B，4.49e6 例
   逐位等价）→ §2.6.4。
4. 「UI 侧缓冲进 CCM」要按 DMA 可达性二分（LVGL 池可进，帧缓冲/推流缓冲不可）→ 暂缓清单。

编号侧（报告曾是 6 个族的属主登记处）：
- 原报告 §9 的 26 行「号 → 现在详述于」对照表迁到 docs/编号规范.md 新增 §4.5，6 族
  owner_docs 改指该节。规范正文含大量写法示例，直接当定义集会误伤，故 check_ids.py
  新增 `_def_owners`：snapshot_only 族剔除规范正文，只恢复可判定、不参与悬空/撞号/裸形
  /紧邻判定（实测若不分，裸形 S1 误报 238 条、S-3 与登记簿 S-3 误判重复定义）。
- 11 个已死号（N-03b/N-10~N-13/N-20/N-21/N-24/N-26/S-1/S-2）在 id_aliases.json 登记
  status=void 并写明去处——它们被约 110 处代码注释与文档引用，原先只靠「报告里顺带提过
  一句」才算有定义，报告一删就集体悬空。N-21/S-1/S-2 一号两义，注记已分别标明。
- 顺带修 id_aliases.json 的 note 被脚本累积重复 26 次；修 registry 里 3 处仍指向改名前的
  任务卡文件名（W1-采集保护收尾.md / W8-数据可信.md），以及 iec104_master.py 两处同类注释。

门禁：check_ids --strict 通过（可判定 8747/10410 = 84.02%，基线由 82.6% 抬到 84.0%）；
check_doc_links --all --sections-strict 通过（177 文档）；pre-commit 相关钩子全过。

scripts/check_test_coverage.py

@@ -15,7 +15,7 @@ r"""
        自研生产源文件里有多少从未被任何主机单测编译过（未触及面 = 覆盖率的 0 分母盲区）。
 
 为什么要它（2026-10-23，W5 验证常态）：
-    docs/问题记录/项目审查与优化建议报告.md §4.8 记的两处空白之一：无覆盖率口径——
+    原评审报告 §4.8 记的两处空白之一（该报告 2026-10-25 已删除）：无覆盖率口径——
     L0.5 只回答“跑过哪些 TC”，回答不了“生产源码里哪些行根本没进过”。用例数与 TC 追溯率
     会随时间上升，但覆盖率照的是另一类真相：**新增分支一行没测**（N-12/N-13 那类“读代码
     才发现”的缺陷，覆盖率是最便宜的机器照法）。
@@ -67,7 +67,7 @@ r"""
     - **PDB 里的源路径大小写会漂**（盘符、VS 根），比对前先按仓库实际拼写归一，否则同一文件
       在基线里裂成两份。
 
-设计依据：docs/测试说明/主机单测覆盖率口径.md；docs/问题记录/项目审查与优化建议报告.md §4.8 §5.5
+设计依据：docs/测试说明/主机单测覆盖率口径.md
 创建日期：2026-10-23
 """