YAO-135: C-3 new-chapter detection by file path (unblocks YAO-106/C04)

[luyao618]

Resolves YAO-135 (C04 blocker arbitration).

Conflict

• CI C-3 (check-code-ratio.ts) required 新增章节: yes in chapter frontmatter to identify new chapters.
• CI C-5 (check-no-frontmatter-in-chapters.ts, YAO-99) bans ALL frontmatter in docs/*.md.
• Any new chapter satisfying C-3 immediately failed C-5. Spec §6.2 row 569 (YAO-99) already declared the new policy ('new-chapter identification comes from §6.2 / appendix manifest, NOT frontmatter'), but the script was never updated.
• Additionally: NN=04 slot is occupied by v1's docs/04-System-Prompt-工程.md, so C04 can't reuse the v1 NN without bundling a v1 rename into the C04 PR (which would pollute C-1 / C-2 gates).

Arbitration

Route B (manifest / file-path). Stays consistent with already-merged §0.1.1 (no chapter frontmatter, ever).

Changes

1. scripts/check-code-ratio.ts: drop frontmatter judgment + NN-prefix set; identify new chapters by an explicit NEW_CHAPTER_FILES path set, with C04 = docs/26-配置迁移即代码.md. Other 7 new chapters added as each issue is scheduled (by OC-Dev).
2. docs/V2-REVISION-SPEC.md:
   • §0.1.1, §0.5.4, §9.3 line 569: point at §9.3.1 as the single authoritative source for new-chapter identity.
   • §9.3.1 (new): landing-file table. C04 → docs/26-配置迁移即代码.md locked; remaining 7 left blank. Rule: new chapters append from NN=26 (v1 occupies 00–25), so no v1 file rename is bundled with a new-chapter PR.

Out of scope

• v1 docs/04-System-Prompt-工程.md stays at NN=04 — its rename to docs/06-System-Prompt-与-Output-Style-注入.md belongs to C06's own PR.
• YAO-106 (C04) issue body updated separately via multica issue update.

Verification

• bun scripts/check-code-ratio.ts --files docs/04-System-Prompt-工程.md docs/26-配置迁移即代码.md → skips v1 file with correct message; would gate the C04 file when present.
• bun scripts/check-no-frontmatter-in-chapters.ts → still passes on all 25 v1 files (unchanged).

source_commit: 290fdc9481a70612bc5823aa4ed225c52c52aad3