docs(覆盖率): 新增 §9 未触及面建桩优先级清单（P1/P2/P3 逐个画像）
回答"那 125 个到底怎么吃"：对 47 个未触及 .c（9,657 有效代码行）逐个量化后再排序，
不靠拍脑袋。排序口径写进文档、可复核可反驳：价值 = 有效代码行 × 逻辑度 × 缺陷历史
（该文件的 fix/refactor 提交数），成本 = 要桩的外部头数 − 能复用的现有桩；逻辑度 =
1 − 硬件符号密度（HAL_*() / FatFs f_*() / CH395F_* / SPI-I2C / OSAL 调用数 ÷ 行数）。
三档（数字互相咬合，覆盖率"不该 100%"在这里是算出来的）：
- P1 先吃 13 个 .c = 2,617 行：配置与工具 429（真实头即可编译，建议第一个落地，先用它
跑通"新增文件进台账 + NOTE 不误报回退"这条链）→ FTP 一套 1,083（20 次提交里 6 次
fix，最近两条都是静默型）→ NET 拆出的四块 903（须新建 stub/ch395f.h）→ 104 服务层 202。
- P2 值得但工程量大 5 个 = 2,226 行：net_socket.c 1,251（51 函数，**必须分片**，先测状态
迁移与语义判据）；假 FatFs 一次吃 sys_log_mcu/cfg_file_store_mcu/soe_store 共 710；
console_log 265（单写者契约 K1/K2 已写成表）。
- P3 明确不做 29 个 = 4,814 行，并把理由写死免得下次又列回待办：芯片驱动 1,990（假到底
≈ 重写驱动，测的是自己的桩）、UI 侧 1,942（与模拟器同一份源码，已由 ui-golden 覆盖）、
任务编排 747（4~5 个函数的装配层，写成单测就是"断言我调了几次"）、app_main 135
（被测对象本身就是内核启动前的时序约束）。
- 恒等式：47 = 13 + 5 + 29、9,657 = 2,617 + 2,226 + 4,814；做完 P1+P2 约 4.8k 行进分母
（现分母 2,893），files_tested 19 → 37。
配套口径修正：
- "125 个未触及"易被读成 125 个待办，三处写精确 = 47 个 .c（9,657 行）+ 78 个 .h
（2,182 行，多为声明与宏）；待办池是那 47 个 .c。
- §8 下一步①改为指向 §9；终点判据从百分比改成"untested_sources 里剩下的每一条都能在
P3 表里找到归属"，并提醒盯 files_tested/files_untested 而不是 88.2%（新增大块未测代码
会把它摊薄，那不是回退）。
自查：check_doc_links.py --all = 35 处（与主干同数，本分支贡献 0；期间修掉一处 §4.5 被
误算成本文自引用）；check_ids.py --strict 通过；check_mojibake + BOM/CR/行尾卫生净。
本轮纯文档，零 .c/.h 改动，未跑 @build、未占 build/bench 锁。
wandering1
e70b861215