docs(plans): 批 0-C1 行数红线落地实施计划

0-C 的原范围（拆超限文件 + 豁免表纠偏）经评估必须拆成三份计划（writing-plans 技能：
多子系统应各自成计划）。本份是 0-C1：口径 + 登记表重建 + 棘轮守卫，即 0-C2/0-C3
（15 个文件的实际拆分）的测量仪器与验收依据。

开工基线的实测数字（控制方全量扫描 868 个文件，ReadAllLines/UTF8 口径）：
- >600 硬限 15 个（前端 5 + Rust 10）；301-600 档 123 个
- 登记表：117 行 / 95 路径，12 组重复、1 条幽灵、1 条已回落、45 条漏登、93 行数值偏差
- 最严重的一条：15 个硬限违规里有 10 个被登记表用 <600 的数字「认证为合规」
- 交叉自洽：93 有效 + 45 漏登 = 138 = 15 + 123 -> 重建后条目数必须是 138

顺带发现的两个治理缺陷（已写进计划）：
- docs-check 有两份内容不同的被跟踪副本，提交钩子与 CI 用的是缺少「剔除代码块」修复的旧版
- scripts/validate-all.mjs 引用 client/ 等本仓库不存在的目录（重构前遗留），跑起来第一步即失败
  -> 并行审查曾建议把行数守卫挂进它，该前提不成立

Task 2 的脚本代码已在真实路径实跑验证（47 处问题 / (c)45 / (d)2 / (a)(b) 空），验证后删除。

Author: Aparencia