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 相关钩子全过。

docs/环境与部署/项目部署环境要求.md

@@ -503,7 +503,7 @@ $env:DTU_KEIL_UV4 = 'D:\NotExist\UV4.exe'   # 仅当前会话，不动用户级
 
 | 资源 | 已用 | 总量 | 利用率 | 余量 | 红线说明 |
 |---|---|---|---|---|---|
-| Flash（`ER_IROM1` = Code + RO） | 232,536 B（227.09 KB） | 1 MB | 22.2% | ≈804 KB | **充裕**：产品需求无 OTA / 双镜像预算，Flash 不是卡点；死代码裁剪簇已收口 → `docs/问题记录/项目审查与优化建议报告.md` §5.4 |
+| Flash（`ER_IROM1` = Code + RO） | 232,536 B（227.09 KB） | 1 MB | 22.2% | ≈804 KB | **充裕**：产品需求无 OTA / 双镜像预算，Flash 不是卡点；死代码裁剪簇已收口 → `docs/内存管理/RAM使用分析与优化方案.md` §2.6.4 |
 | 主 SRAM1（静态区；FreeRTOS 堆已迁 CCM） | 75,264 B（73.5 KB） | 128 KB | 57.4% | 55,808 B | 已不紧张——2026-10-11 堆迁 CCM 与 2026-10-15 `LV_MEM_SIZE` 40→16 KB 两步的结果 |
 | CCM（`RW_CCM` 段） | 57,376 B（56.0 KB） | 65,280 B | **87.9%** | **7,904 B** | **当前真正的红线**：加任务 / 抬栈 / 加堆会先在这里撞墙；`mem-budget` 钩子在 92% 拦提交 |