ci: cut the GitHub Release, and fix the Windows registry rename race

[Vieeeeeee]

仓库首页一直写着 Latest: v0.2.0 · 3 days ago，而 npm 上早就有 0.3.0 / 0.4.0 / 0.5.0 了。

原因：发布流程只做 npm publish，从来没有创建 GitHub Release 的步骤。标签推上去了，Release 没建。落到访客眼里就是一个停更三天的项目——而且代码里 checkSelfUpdate 给用户的 releaseUrl 指的正是这个页面。

（0.3.0 / 0.4.0 / 0.5.0 三条 Release 已手动补齐，这个 PR 是把坑堵上，以后不用再补。）

改了什么

在 npm publish 之后加一步 gh release create：

• 放在 publish 之后 → Release 绝不会宣告一个还装不到的版本
• 说明取自 CHANGELOG 里对应版本那一节（标签存在之前就写好了）
• 抽不到内容就让这一步失败，而不是发一个空说明的 Release
• --verify-tag 拒绝远端不存在的标签
• 新增权限只有 contents: write 一项

验证

awk 抽取逻辑在真实 CHANGELOG 上跑过：

版本	抽出行数	是否串到下一节
0.5.0	48	否
0.4.0	44	否
0.3.0	25	否
9.9.9（不存在）	0	— 会让步骤报错退出

YAML 无 tab 缩进。

🤖 Generated with Claude Code

[Vieeeeeee]

补一个提交：CI 在 windows-latest 上挂了，查出来是长期存在的间歇性竞态，不是这个 PR 引入的（近 12 次 CI 里挂过 2 次）。

EPERM: operation not permitted, rename '...tmp' -> 'registry.json'

每条命令跑完都会重建 registry.json，而这一步在 override 锁释放之后。两个并发的 describe 就会撞在这一次 rename 上。POSIX 直接换 inode 永远成功；Windows 不允许 rename 到一个被别的进程打开着的文件。结果是：写其实成功了，命令却报失败。

改法是有上限的短重试——这个文件没人会长时间持有。加锁是更重的答案，而且对一个可重建的缓存不值得；真正不可重建的 overrides.json 早就有锁了。

回归测试就是那条挂掉的 parallel metadata writes keep every edit，不需要新增。

本地 98/98，ops.test.mjs 连跑 5 轮全绿。