v0.1.12

这次修的是什么

「远端有没有这个 tag」这条事实，在 matrix-tools 里有三条读取路径，却有两种语义。

#79 把「读到空 ≠ 事实为空」在 GitHub API 侧（ghsafe）与 git 传输侧
（matrix.remote_tags）都做实了——读不到就抛 RemoteReadError。但另外两条
读取路径仍是旧语义：只看 git ls-remote 的 stdout 非空 ⇒ 读失败 = 「不存在」。

#	路径	用在哪	读失败时的行为
1	matrix.remote_tags	audit / gen_versions	抛 RemoteReadError（#79）
2	release_train.tag_exists_remote	发版检查面 a「同名 tag 查重」	False =「不存在」⇒ 查重门禁静默放行
3	close_issue.tag_on_remote	关单守卫「tag 必须已存在于远端」	报「tag 不在远端」——把「读不到」说成「没有」

变异实测（修复前）：同一个确实存在于远端的 tag，只因读法不同就从「存在」
翻成「不存在」——

读法	读成功	读失败
release_train.tag_exists_remote	True	False
matrix.tag_exists	True	False

怎么修的

• matrix.remote_tag_exists：这条事实的唯一读法（走 matrix.remote_tags：
  canonical HTTPS 优先 → origin 兜底 → 失败抛 RemoteReadError）；
  matrix.tag_exists 收口到它，不再自带第三种语义。
• release_train.tag_exists_remote 改走它；check_module 接住 RemoteReadError
  ⇒ fail-closed（不进打 tag 环节），错误信息写明「读不到 ≠ 不存在」。
• close_issue.tag_on_remote 改走它；读不到 ⇒ 报「读不到远端 tag（不是不存在）」，
  并明确不要用 --force 绕过（--force 是刻意的越权 ⇒ 显式跳过核对、不发读请求）。

为什么值得单独修

• 发版查重形同虚设：release_train 的 docstring 写着这条检查的理由——
  「重推 = 代理/sumdb 缓存集体中毒，.github#5」——恰在最需要它的时刻（SSH 掉线 /
  网络抖动）放行。真正拦住重推的是 git push 自身（实测同名 tag 无 --force 推送被拒：
  ! [rejected] v1.0.0 -> v1.0.0 (already exists)，远端 tag 指向不变）⇒ 不会真的
  重推成功，但脚本会在 git tag -a 之后崩在 push、留下半截本地 tag，报错是
  「already exists」而不是「查重时读不到远端」——排查被带偏。
• 关单守卫误报：--force 在脚本文案里就写着「确实要引用未发版本需 --force」
  ⇒ 读失败被误报成「不在远端」，会把人推向 --force，而真实原因可能只是网络抖了
  一下 ⇒ 守卫生效的路径被误诊成「刻意的越权」。

验证

• 变异回归：M1 release_train 退回旧语义 ⇒ K 转红；M2 close_issue 退回旧语义
  ⇒ M 转红；M3 matrix 退回旧语义 ⇒ I 转红；3/3 转红，还原后 14/14 全绿。
• scripts/remote_reads_selftest.py 加 6 组用例（I/J/K/L/M/N）：三条读路径各自的
  「读失败必抛」与「读成功必判存在」。该脚本已接进 audit.yml 的 selftest job
  ⇒ 自动进 CI 覆盖（PR #86 的 selftest job 已绿）。
• 其余四个 selftest（close_issue / dependabot_dirs / ghsafe / verify_release_units）
  全绿；audit.py --remote-tags 仍 ✓ 矩阵审计通过（远端 tag 读取 24/24 仓成功）；
  PR #86 CI 全绿（含 audit job）。

Closes #85