fix(release): config.yaml 从 RP 的 extra-files 摘掉，并给每条自动位加"真能命中"的闸

[ReSerendipity]

为什么要改

#121 把 5 处版本位挂进 release-please-config.json 的 extra-files，合进 main 后 release-please
立刻刷新了 #120（2.2.4）。这就是它第一次在真 PR 上被验，结论是有一条不能留：

$ git diff origin/main...pr-120 -- config.yaml | diffstat
 config.yaml | 320 +++++++++++++++++++-------------------

type: yaml + jsonpath: $.version 名义上只改第 1 行，实际是 160 增 / 160 删（整份 232 行重写）。
注释行从 96 行变成 0 行（git show origin/main:config.yaml | grep -c '#' = 96，
git show pr-120:config.yaml | grep -c '#' = 0）。被洗掉的包括：

• models.model_source_mode 上面那段 portable / shared 选型说明（6 行）
• server.ssl 怎么打开 HTTPS 的 3 行说明
• vram_safety_margin_gb: 1.5 的行内算式注释
• "127.0.0.1" / "" 的引号被规范化掉

同一条 PR 上另外 4 条（json × 3 + toml × 1）都是干净的 1 行改动 —— 破坏性是 yaml 写入器
特有的：它 parse 完再 dump，不做原位替换；generic 才是行内正则替换（读了 release-please 的
src/updaters/generic.ts 确认：标记与版本号必须同一行，替换的是那一行里第一个 x.y.z）。

改了什么

• release-please-config.json：删掉 config.yaml 那条 → 它回到手工同步（与 Cargo.lock /
  setup.nsi / k8s 镜像 tag 同一类）。
• tests/test_version_consistency.py：
  • _RP_MANAGED 去掉 config.yaml，账写在它上方的注释里；
  • 新增 test_extra_files_entries_are_all_actionable：类型只允许 json|toml|generic，
    并逐条走 jsonpath 确认"当前取到的值就是 canonical 版本号" —— 配错 key、文件搬家、
    字段改名都当场红，而不是发版当天发现 RP 静默少抬了一处；generic 则要求行内标记在场；
  • 新增 test_bundled_changelog_describes_its_own_version：RP 只抬 version.json 的
    $.version，不抬同文件的 changelog / release_date，而 desktop/src-tauri/src/updater.rs
    会读本地 version.json 的 changelog 展示给用户 → 拦住"自称 2.2.4、说明写着 2.2.3"的壳。
• docs/release-governance.md：§1 重写成"自动 5 处 / 手工 4 类"并写明 yaml 为什么不能用；
  手工发版流程补第 4 步（发完把 .release-please-manifest.json 抬到刚发的版本，否则两边在
  版本号上互踩）；把两处已经过时的"release-please.yml 是结构性空转"改掉 —— 它现在真的会开 PR。

验收（每条闸都做了变异复验，不是"跑过了"）

动作	结果
基线	test_version_consistency.py 8 passed
把 {"type":"yaml","path":"config.yaml"} 加回去	红在 test_extra_files_entries_are_all_actionable + 标注一致性
把 Cargo.toml 的 jsonpath 写成 $.package.versions	红在 ..._are_all_actionable（走不到 key）
只把 version.json 的 version 抬到 2.2.4（RP 的真实行为）	红 3 条：版本位互相矛盾 / actionable / changelog 与自身版本不符
还原	8 passed，git status 只剩本次改动
相邻回归	test_release_robustness + test_integrity_selfcheck_packaging + 本文件 = 24 passed
其他门禁	ruff check 通过；scripts/check_spec_refs.py 退出码 0；pre-commit 钩子无 Failed

追加：这条 PR 自己写错了一次，红在 CI 的 3.10 上（不是我改之前就有）

test_extra_files_entries_are_all_actionable 在 Test (pytest) (3.10, {ubuntu,windows,macos})
三条全红，签名是同一条：

desktop/src-tauri/Cargo.toml：jsonpath $.package.version 走不到
  （__unread__:py<3.11 无 tomllib（该文件已由 _site_versions 的读取器覆盖））

我把"这个解释器没有 TOML 解析器"和"jsonpath 走不到 key"塞进了同一个 __unread__ 前缀，
于是缺解析器被当成配置错误。更糟的是注释写着"已由站点读取器覆盖"，代码却走 pending.append
—— 兜底那句根本没跑。我本地只有 3.12（.venv 是 3.12.10），所以这条只有 CI 能暴露。

第二个 commit（7289969）改成独立的 _NO_PARSER 哨兵：命中它就交给
test_all_version_sites_agree（对 Cargo.toml 有正则读取器），只有连站点表都没覆盖这一位才红。
两向都按上面的老办法验（把 sys.modules["tomllib"] = None 模拟 3.10）：

情形	3.10 模拟	3.12
基线	4 条目标函数全 PASS	8 passed
把 Cargo.toml 的 package version 改成 2.2.9	test_all_version_sites_agree FAIL（证明兜底在真跑，不是静默跳过）	parity + installer 命名 + actionable 三条 FAIL
还原	—	8 passed

合并之后会发生什么（不是"预计"，是会被复看的两件事）

1. RP 会在 main push 后重新刷新 chore(main): release 2.2.4 #120。预期它 config.yaml 那 320 行从 PR 里消失；
   若还在，说明它没重算而是沿用旧 release 分支 —— 那就手工关掉 chore(main): release 2.2.4 #120 让它重开。
2. chore(main): release 2.2.4 #120 会故意红在版本位一致性测试上：RP 抬了 5 处自动位，config.yaml / Cargo.lock /
   setup.nsi / k8s tag / version.json 的 changelog+release_date 是手工位。这是 §1 写明的预期行为，
   补一个 commit 即可。发版本身（tag + Release）仍按约定停在 owner 手上。

没覆盖到的

• 没在真 runner 上验证 generic 类型（本 PR 没有新增 generic 条目，只写了它的命中检查逻辑）。
  第一次真用它的那条 PR 需要照例看 diff 行数。
• desktop/package-lock.json 与 scripts/installer/version.json 都在 .gitignore 里，
  不在任何闸的覆盖范围内 —— 它们是装配期产物，只能在真装/真打包那一步核对（仍等 owner 点头）。