chore: 发版 0.9.1

package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-cura",
-  "version": "0.9.0",
+  "version": "0.9.1",
   "type": "module",
   "main": "lib/index.js",
   "description": "生活关怀层（健康记录/周期关怀/常用坐标/出行与点单 MCP，全会话可用）+ QQ 伴生增强（拟人化情境表达规则库、语料、通话引擎大脑路由）",

release-notes/v0.9.1.md

@@ -0,0 +1,36 @@
+# v0.9.1 — 打标签就能发版
+
+这一版没有功能改动，只是把「发版」这件事从手工变成推标签就自动跑。顺带修掉上一版实跑时暴露的一个误判。
+
+### 推 v* 标签，整条链路自己走
+
+之前发 0.9.0 是手工的：本地 `npm publish` 卡在 2FA，tag 手打，Release 正文靠 `--generate-notes` 拼出一堆 `Merge pull request #N`。每次都要人盯着，也没法保证每次都一样。
+
+现在推一个 `v*` 标签，三段 job 依次跑：
+
+| 段 | 做什么 | 为什么这么排 |
+|---|---|---|
+| **test** | Node 20 / 22 双档跑全套单测 | 装法与 `test.yml` 一致，否则测不到 `rules-remote` 的降级形状 |
+| **publish** | 校 tag 版本 → 查 registry → `npm publish --provenance` → 回查 | 先校版本再发：npm 上的版本号发出去改不了 |
+| **release** | 列提交 → 拼正文 → `gh release create` | 等 publish 成功才建 Release，发不出去不该先挂一个出来 |
+
+### Release 正文固定成四段
+
+描述 / 本次变更 / 安装 / 链接。提交从「上一个 tag..本 tag」取，过滤 merge 与 `chore: 发版`；想写人话就放 `release-notes/v<版本>.md`，首行 `# 标题` 会被摘成 Release 标题。
+
+你现在读的这份就是那种文件。
+
+### 修掉一个误判
+
+第一次实跑 v0.9.0 时，`npm publish` 明明成功（provenance 都发到 sigstore 了），紧接着的回查只等 30 秒就判失败，`release` job 被跳过、整个 run 红着。
+
+npm 自己写着「may take a few minutes to become available」——我给的窗口比它声明的延迟还短。现在改成 4 分钟（`24 × 10s`），查询加 `--prefer-online` 绕过 CDN 缓存，每次未命中打印第几次重试，失败时能看出是「一直没上去」还是「最后才上去」。
+
+### 工程
+
+- 新增 `tests/test-release-body.mjs`（7 组），已接进 `tests/all.mjs`：**8 套全绿**。
+- 八条变异自证，全部 `EXIT=1`，还原后全绿。其中 M4 值得记一笔：把 tag 校验改成恒真，原断言照样绿——静态接线断言只查「错误文案存在」会漏掉「分支永不触发」，必须同时断言判定表达式本身。
+- `ref: ${{ env.RELEASE_TAG }}` 改成 `github.event.inputs.tag || github.ref_name`（3 处）：env 上下文在 step 的 `with:` 里不可用。
+
+功能与 0.9.0 完全一致，可以按需升级。
+