fix(ci): release-please 三处静默失效——它其实从没发过版（merge 需等 v2.2.2 tag 落地）

[ReSerendipity]

现象与定位

三次「绿色」的 main push 之后既没 tag 迁移也没 Release（v2.2.2 就是这么拖出来的）。读日志后确认是三处互相独立的静默失效，而不是"上游偶发失败"：

#	失效点	证据
1	skip-github-pull-request: true 让 RP 只从"已合并的 release PR"发版，而本仓从没有过一个	run 35620031352 输出 found 0 possible releases 后 success
2	传了 5 个 v4 不认的入参，配置整段被忽略	同一 run 的 ##[warning]Unexpected input(s) 'package-name','changelog-path','draft','label','prerelease', valid inputs are [...]（已与 action.yml 的 inputs 表逐条比对）
3	release-please job 没有 outputs: 块，而 build-release 把门写在 needs.release-please.outputs.release_created == 'true' 上、还引用 ...outputs.tag_name	两个引用恒为空 → 即便 RP 正常发版，sdist/wheel + twine check + SHA256SUMS 也永远不出产物

仓库里也没有 release-please-config.json / .release-please-manifest.json，所以"配置写在 with 里"这件事从未成立。

改法

• 删无效入参与 skip-github-pull-request，配置落到那两个文件（release-type: python +
  changelog-path: CHANGELOG.md + manifest 登记 2.2.2）；
• 补 outputs: 映射（输出名按官方文档为下划线式：release_created / tag_name / version / pr）；
• 新增一步把结果写进 job summary，两者皆空时明确区分"确实没有约定式提交"与"失同步"；
• 新增硬自证：配置文件存在且为合法 JSON、必须有 v* tag、manifest 落后于最新 tag 直接失败
  （那会让 RP 重算已发布版本），领先（发版进行中）只 WARN。
  比较用 sort -V，5 个情形本机逐条验过，含 2.10 vs 2.9、10.0 vs 1.0 这种字典序会判错的两例。

已知代价（写明，不藏）

extra-files: [] —— RP 只会自动改 pyproject.toml + CHANGELOG，另外 8 处版本位
（version.json / config.yaml / 桌面壳 3 处 / 安装器 / k8s 镜像 tag）仍靠人工。
所以下一条真正的 release PR 会被 test_all_version_sites_agree（#113 加的）判红。
这是有意的闸：红 = 有人来同步，而不是静默发出一堆版本互相矛盾的产物。要交给 RP 就逐条填
extra-files，并且必须在一次真实 release PR 上验 —— 我没法在这里验证 RP 对每个文件的改写行为。

合并顺序

等 v2.2.2 的 tag 落地之后再合，否则 manifest(2.2.2) 领先最新 tag(v2.2.1) 会让自证步骤长期挂 WARN。
（当前 v2.2.2 尚未发布：gh release list 最新是 v2.2.1，2026-08-22。）

本地验证

python -c yaml.safe_load 通过（4 步、outputs 两项、RP 只剩 2 个合法入参）；
scripts/verify_cloud_native.py 全绿；scripts/check_spec_refs.py → new=0；pre-commit 通过。