fix(cache): 发布侧 key 只取 inputs.os 且 tag run 只读不写（M270 r1 复审 P2）

r1 复审（p2-1items）指出：tag 触发的 run 只能读 main 或同名 tag 的缓存，而 main 上
没有任何 job 跑 ubuntu-22.04 / windows-11-arm 这些标签 ⇒ 发布侧四个槽位每次发布都是冷编，
写出的 target 缓存永远拿不回来，还会占 10 GB 配额把 main 的热缓存 LRU 挤掉。r0 的
「key = inputs.os + inputs.slot」既没解决死缓存，还把 Windows 借 main 热缓存的路掐了。

- 发布侧 key 改成 `${{ inputs.os }}`：linux-x64(22.04) 与 main 的 ubuntu-latest 仍然不同
  key（M269 那条必须断），而 windows-x64(windows-latest) 与 main 的 ci/build 重新同 key
  —— 同镜像，借它的热缓存安全（M270 前 Windows 一直走这条且产物是绿的）。
- 发布侧加 `save-if: ${{ github.ref_type != 'tag' }}`：tag run 一律不写（写出来是死缓存），
  只有 main 上的 dispatch 预热会写 —— 那次 run 的作用域是 main，之后的 tag run 才读得到。
  刻意不用 `cache-targets: false`：那会把 Windows 借热缓存的路一起掐掉。
- ci.yml 侧只修 Nit：`Linux-X64` → `Linux-x64`（node 的 os.arch() 是小写）。
- docs 照实重写：tag 缓存作用域、发布侧每次冷编的必然性、预热怎么做、只读不写防什么、
  「同一镜像标签但底层悄悄升级」这档剩余风险与手动 bump 办法；并补回 M164 MSYS 报错的
  原文（可搜索的指路）。新的 key 演算：改前主 key 相同 2 对（跨镜像 1 对）/ 跨镜像前缀
  命中 2 组；r1 = 1 对（全是同镜像 windows）/ 0 组。

.github/workflows/ci.yml

@@ -4,9 +4,9 @@ name: CI
 # 架构守门（core 零 UI、文件 ≤400 行、依赖许可）见 guards.yml。
 # 平台基线 Win10+（标准工具链产物），平台矩阵见 AGENTS.md §7。
 # （M270）每个 `Swatinem/rust-cache@v2` 都显式写 `key:` = **该 job 的 runner 镜像标签**（不是「更保险」）：v2 的 key
-# 只有 `os.type()-os.arch()`（`Linux-X64`），**没有镜像标签/glibc** ⇒ 本文件 `build`（ubuntu-latest = 24.04）与
-# `release-build.yml` 的 `build`（ubuntu-22.04 = glibc 2.35）共用同一份 `target/`。因果链见 `release-build.yml`
-# 那处注释；`cache-targets` 取舍、剩余风险与 key 演算见 packaging/docs/build-and-ci.md §3「构建缓存」。
+# 只有 `os.type()-os.arch()`（`Linux-x64`），**没有镜像标签/glibc** ⇒ **改前**本文件 `build`（ubuntu-latest = 24.04）与
+# `release-build.yml` 的 `build`（ubuntu-22.04 = glibc 2.35）共用同一份 `target/`（脏产物就是这么串过去的）。因果链见
+# `release-build.yml` 那处注释；`cache-targets` 取舍、剩余风险与 key 演算见 packaging/docs/build-and-ci.md §3「构建缓存」。
 #
 # M118（D26）：根 Cargo.toml 已 `exclude = ["crates/app"]`（Slint 退役树，源码原样保留）。
 # 所以本文件里所有 `--workspace` 都**不再**覆盖 `unlucky-app`：CI 不再编 slint 1.18 + usvg 0.48