fix(tools): parity runner 计数失配收口——CORPUS_TOTAL 75→76（第一腿自 2026-09-18 恒红；#132 加语料未同步）

[dslsdzc]

缺陷：回归网第一腿自 2026-09-18 起恒红

tools/baseline/parity_run.sh 的 CORPUS_TOTAL=75，而实数 = 76。fail-closed 断言（:73-75）因此硬失败：

CORPUS COUNT 76 != 75 —— 语料构成已变；须显式更新本 runner 的分层清单与计数（硬失败，不得静默）
exit 1

定位：#132（批8 2(a)，2026-09-18 21:54）新增 tests/suite/cli_view_test.cr（+30 行），未同步计数。而 parity_run.sh:33 的注释自己写着「档数变化必须同批改本行与本注释，否则 runner 硬失败」—— 正是这条被踩了。

为什么 6 天没人发现：parity 不在 PR 门里（门只 3/5：check / bootstrap-tests / selfhost-tests），而 REBUILD.md「已知限制」载明 CI 环境是浅检出、无 jj ⇒ pinned revision 不可得 ⇒ parity 是手工判据。⇒ 计数漂移没有任何机械发现渠道。

修法

文件	改动
parity_run.sh	CORPUS_TOTAL 75 → 76；t1 35 → 36；三处提数同步（:2 的「75 档」、:11 的「计数断言」、:32 的常量）；注释里补第四次 +1 与失配留痕
REBUILD.md	配方段档数 75 → 76（tests/suite 36）；:8 原引 parity_run.sh:31 的行号去掉（行号会漂）
REBUILD.md :130	原文保留 + 加注：36×0 / 39×1 是 75 档时的实测值（2026-09-17），76 档的分布与划界须下次采基线时重采

核验（本 PR 做了什么、没做什么）

• 用 runner 自己的枚举逻辑复算：t1=36 · t2=2 · t3=15 · t4=19 · t5=4 ⇒ 76（shopt -s nullglob 逐层 glob，与 :48-65 逐字同构）。
• bash -n tools/baseline/parity_run.sh 通过。
• ⚠ 未跑 runner（零构建）⇒ 只证明了「计数与实数相符」，没有证明 76 档的 rc 分布/日志。⇒ REBUILD.md 那句分布已按此加注，不得当已重采使用。

遗留（不在本 PR，建议登记）

计数同步没有机械判据。但存在一条不需要 pinned 二进制、也不需要 jj 的静态检查：把脚本里的 CORPUS_TOTAL 与按脚本自身 glob 复算的数对比 —— 可进 CI。本次若早有它，2026-09-18 就会红。

本 PR 是迁移前的必要前置：v4 语法迁移要「先采一次冻结基线」，而基线采在一张恒红的网上没有意义。