fix(release),ci(gates): 修回 main 的锁文件版本漂移并加一致性门禁

[GGGBB]

main 现在是坏的（版本漂移）

Cargo.toml = 0.3.3，Cargo.lock = 0.3.2——v0.3.3 的 bump 只改了一处。
两类后果都真实发生过：

1. 日常每次 cargo 调用都会悄悄重写锁文件，工作区凭空多出未提交改动，
   git pull 被挡。本仓库已经两次靠「先 stash、比对与 main 一致再 drop」才能继续。
2. 任何用 cargo build --locked 的地方直接报错：
   cannot update the lock file ... because --locked was passed。发版链路上就是红。

本 PR 做两件事

• 修回：cargo metadata --format-version 1 --offline 同步锁文件，只动本包那一行版本号。
• 防复发门禁 scripts/ci/lock_version_gate.py：判据是纯函数 decide，只比对本包
  自己的 version 行。刻意不校验依赖解析结果——那是 --locked 的职责，写进来会把
  正常的依赖升级拦在门外。

判据健康度

• --self-test 四例：一致放行、漂移判红、manifest 与 lock 两条解析各自正确、
  锁文件缺本包条目显式报错（那是判据自身失效的形态，绝不放行）。
• fail-loud：两个文件任一读不到 → 退出码 2，不把「读不到」当成「一致」。
• 挂进 gates job；必需检查名一字未动。

有效性反向验过

把锁文件还原成 main 现在的漂移状态 → 立刻判红并给出离线同步命令；恢复 → 判绿。

现场计数

cargo test --all-targets 11 个 target 全部 ok、零 FAILED；lib 194 / bin 6 / 接线集成 9 /
protocol_proxy 189 / 监看 8 / 持久化 e2e 1 不变；lib 侧 never-used warning 仍 3 条；
两条中性化判据整树零命中。

贡献指南补的那条

发版 bump 必须两处在同一笔 commit，并给出本地同步命令（离线，不访问网络）。
这条不写进文档，下一次 bump 还会重犯——毕竟这次的 bump 就是我自己做的。

[GGGBB]

合并前对账（维护者复核，head 0a2df8f）

CI 四检查全绿。本 PR 修的是 main 当下就存在的坏状态，不是假想风险——
Cargo.toml=0.3.3 配 Cargo.lock=0.3.2 是我发 v0.3.3 时只改一处造成的，
两类后果（cargo 悄悄重写工作区挡住 git pull；--locked 直接报错）我在本会话里
都被咬过，只是当时当成「环境噪音」绕过去了，没升因到「main 是坏的」。这次落判据。

三点我核过

1. 改动面最小：锁文件只动本包那一行版本号（git diff --stat = 1 行），
   没有任何依赖解析结果变化——用的是 cargo metadata --offline，不访问网络。
2. 判据窄而正确：只比对本包 version 行，不碰依赖解析（那是 --locked 的职责，
   混进来会把正常依赖升级拦在门外）。这个边界我喜欢。
3. 判据自身失效有对照：夹具里专门放了「锁文件缺本包条目」一例，要求显式报错。
   少了这条，一个把正则写岔的门禁会永远「找不到包 → 无违规 → 绿」。

反向验过

把锁文件还原成 main 现在的漂移状态 → 立刻判红并给出离线同步命令；恢复 → 判绿。

一处遗留、不拦合并

gates 门禁判的是「工作区当前内容」，本仓库 CI 跑在 checkout 上，没问题；
但 release.yml 里两处 cargo build --release 仍未加 --locked，所以发版链路
还是不会被漂移拦住——真正拦住它的是 gates job 在 PR 阶段的红。要不要统一改成
--locked（并配 cargo update 的显式流程）值得单独一单权衡：加了发版更硬，
代价是任何依赖升级都得先本地刷锁文件才能发版。我倾向加，但不在本 PR 里顺手做。

流程偏差声明

代码与门禁由维护者会话编写，单账号下无法自审 APPROVE，以本条评论留对账依据后执行
rebase 合并。本条评论即合并前的批准口径留痕（供 self-approval aftercheck 交叉）。