docs(规格): T0 补齐——探针修一处空壳绿（空语料 0==0 PASS）+ tokenize 两口径（9/10 含 LSP 站）+ 字面量花括号拆四格

[dslsdzc]

这是什么

#173 的补齐（T0 规格 + 探针的第二版）。#173 合的是 849 行 / 1081 行；本 PR 是 899 行 / 1169 行（+206 / −68）。

⚠ 本 PR 的来历要如实说：作者在我把 #173 合入 develop 之后又在继续改，而我的 jj git fetch/合并把它共享工作区变成了 stale。它拒绝跑 update-stale（理由是铁律 #3 需许可、且该操作在本仓有内容丢失前科），改为把两档 cp -a 到 /tmp/t0_guard/ 并把决定权交回。我按本仓既有的配方救回：库外副本 → update-stale → 恢复 → 立即提交，并逐个 sha256 核对（不信 commit id）：

f7226fe9a8d075d9…  v4-layout-spec.md   899 行
075b7d990ab8a76e…  v4_layout_probe.py  1169 行   （与 /tmp 守卫副本逐字节相同）

一、修掉一处空壳绿（本 PR 最重要的一条）

探针旧版：文件清单走工作副本 os.walk、内容走 jj file show，而读失败被 except SystemExit: continue 吞掉 ⇒ 语料变成空集 ⇒ --form 断言 0 == 0 直接 PASS（rc=0）。

⇒ 这就是「空壳绿」：判据看起来绿，实际什么都没测。三处修：

1. fail-closed：读不到 / 清单为空 / 扫到 0 档 ⇒ PROBE ERROR + rc=1，绝不返回 0；
2. 清单与内容同源：带 --rev 时清单走 jj file list -r，不再 walk 工作副本 ⇒ 落后检出不能静默缩小语料；
3. 修掉修补中自己引入的一处回归（prefixes=(".") 永不匹配真实相对路径 ⇒ 又成空集）。

实测：stale 下带 --rev 的判据现在一律 rc=1 + 明确提示；去掉 --rev 读完好的工作副本，13 条文档命令逐条行为与文档一致。

二、两处计数/措辞按实测改（一处是改我的读数）

① tokenize() 调用点 —— 两个口径都写死：

口径	数	明细
src/compiler/（T1/T2/T5 复核面）	9	裸 grep -rnE '\btokenize\(' = 12 → −定义行 = 11 → −2 处纯注释提及 = 9
src/** 全域	10	第 10 处 = src/lsp/lsp.cr:173（真调用）

⇒ 计划 §7.2 写的「12」= 裸 grep 命中行数（含定义行与 2 处注释），出处已写清。我先前给作者的「9 处」限定在 src/compiler/*.cr，漏了 LSP 那一处 —— 作者保留两口径是对的，否则 T5 按清单复核时会漏 LSP 站点。

② 字面量花括号拆四格（原文自相矛盾已消除）：src/compiler 内 1 处真字面量花括号（= 2 个字符）= elf.cr:45，不退场；另 1 处注释提及 = parser.cr:1201（且那是 struct 模式，:1202 逐字 EXPR_STRUCTPAT）⇒ 零字符，T4 既不算「要改的」也不算「不退场的」。

三、复验读数（完好的工作副本）

struct-lit = 14/8 · 18/9 · 32（src/compiler = 1）· colon-positions = 227 档 / 行内 7354 / 行尾 region 开启 0 / CANDIDATE 0 · tokenize-sites = 12 / 1 定义 / 2 注释 / 9 / 10 · semi-resolvers --spec = 35/35，MISSING 0、stale 0。

本 PR 只改这两档，未改任何其它文件。