chore(packaging): 收 M46 r1 六条 P3（dumpbin 门禁/ref 注入面/重跑幂等/文档口径）

- O1 release.yml 找不到 dumpbin 从 ::warning+exit 0 改为 ::error+exit 1（门禁不降级），
  README §7.4 同步为"两侧都 fail、没有降级分支"
- O2 打包 step 改用 env REF_TYPE/TAG 传参，bash 里不再出现 ${{ }} 直插；
  release job 的 TAG/PRERELEASE 已是 env 写法，全文件复核无同类风险点
- O3 gh release create 改为 view 命中则 upload --clobber + edit，同 tag 重跑幂等；
  README §3 补重跑语义与 pre-release 标记以首次创建为准
- O4 yml 头注释与 README §3 点明 inputs.prerelease 只在 tag ref 上 dispatch 可达
  （UI 只能选分支，需 gh workflow run --ref v<tag>），不与"dispatch 只构建不发布"冲突
- O5 release-notes 模板补 Termux 试验级行，README §9 同口径，标题改为"逐行一致"
- O6 README §6 补 ci.yml 每次 push/PR 的 release build 吃 fat LTO 链接时间；
  订正"fat 是全局单线程 LTO"为 codegen-units=1 导致单线程（§6/§7.1 两处）；
  §7.3 写入 reviewer 补测的 tar 可复现证据 a99d6e9e…92f8

.github/workflows/release.yml

@@ -1,11 +1,16 @@
 name: Release
 
 # 发布流水线：tag `v*` → 三平台（四槽位）矩阵构建 → 单文件产物 + SHA256SUMS
-# → 上传 artifact + 创建 GitHub Release（pre-release 默认开）。
+# → 上传 artifact + 创建 GitHub Release（pre-release 默认开）。同一 tag 重跑幂等：
+# Release 已存在时覆盖资产与说明，不再 `gh release create`（见 release job 末步）。
 #
 # 契约唯一真相源：packaging/README.md（命名/目录/运行时依赖）。
 # 打包本体在 packaging/make_artifacts.py（本地与 CI 同一份脚本，逐字节同布局）。
-# 手动触发（workflow_dispatch）只跑构建不建 Release —— 用来验证矩阵仍然编得过。
+# 手动触发（workflow_dispatch）默认只跑构建不建 Release —— 用来验证矩阵仍然编得过。
+# 注意 `inputs.prerelease` 只在 **tag ref** 上 dispatch 才可达：Actions 页面的
+# "Run workflow" 只能选分支，要跑 tag 得 `gh workflow run release.yml --ref v0.1.0`。
+# 分支 ref 的 dispatch 与 push 事件一样被 release job 的 `if: github.ref_type == 'tag'`
+# 挡在发布之外，所以「dispatch 只构建不发布」与「dispatch 可关 pre-release」并不矛盾。
 
 on:
   push:
@@ -14,7 +19,7 @@ on:
   workflow_dispatch:
     inputs:
       prerelease:
-        description: "标记为 pre-release"
+        description: "标记为 pre-release（仅在 tag ref 上 dispatch 时才生效）"
         type: boolean
         default: true
 
@@ -81,9 +86,11 @@ jobs:
           if [ -z "$DUMPBIN" ]; then
             DUMPBIN=$(ls -d "C:/Program Files/Microsoft Visual Studio/"*/VC/Tools/MSVC/*/bin/Hostx64/x64/dumpbin.exe 2>/dev/null | head -n1 || true)
           fi
+          # 工具缺失同样 fail：windows-latest 自带 VS 工具链，基本找得到；
+          # "找不到就跳过"等于让这道门禁在最需要它的时候静默失效。
           if [ -z "$DUMPBIN" ]; then
-            echo "::warning::找不到 dumpbin，跳过导入表自检（不阻塞发布）"
-            exit 0
+            echo "::error::找不到 dumpbin，无法校验导入表（静态 CRT 门禁不降级）"
+            exit 1
           fi
           "$DUMPBIN" -nologo -dependents target/release/unlucky-launcher.exe | tee dependents.txt
           if grep -Eiq 'VCRUNTIME|MSVCP|MSVCR|ucrtbase\.dll' dependents.txt; then
@@ -93,13 +100,17 @@ jobs:
 
       - name: 打包（产物 + SHA256SUMS）
         shell: bash
+        env:
+          # 不把 `${{ }}` 直接拼进 bash 脚本：git ref 名允许 `$`/反引号/`"`，一律经 env 传入再展开。
+          REF_TYPE: ${{ github.ref_type }}
+          TAG: ${{ github.ref_name }}
         run: |
           set -euo pipefail
           # git-bash 与 Linux/macOS runner 的 python 入口名不一致，先探一遍。
           PY=$(command -v python3 || command -v python)
           args=()
-          if [ "${{ github.ref_type }}" = "tag" ]; then
-            args+=(--version "${{ github.ref_name }}")   # 与 Cargo.toml 版本交叉校验
+          if [ "$REF_TYPE" = "tag" ]; then
+            args+=(--version "$TAG")   # 与 Cargo.toml 版本交叉校验
           fi
           "$PY" packaging/make_artifacts.py "${args[@]}" --out dist
           ls -l dist
@@ -179,7 +190,7 @@ jobs:
           print(body[:400])
           PY
 
-      - name: 创建 GitHub Release（pre-release 默认开）
+      - name: 创建或更新 GitHub Release（同 tag 重跑幂等）
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           TAG: ${{ github.ref_name }}
@@ -193,8 +204,12 @@ jobs:
           fi
           # Windows 单 exe 装不下 LICENSE/NOTICE/README.md，这三份与产物并列挂到 Release 上，
           # 保证每个下载平台的许可条款都随包分发。
-          gh release create "$TAG" \
-            dist/unlucky-launcher-* \
-            dist/SHA256SUMS.txt \
-            LICENSE NOTICE README.md \
-            "${flags[@]}"
+          assets=(dist/unlucky-launcher-* dist/SHA256SUMS.txt LICENSE NOTICE README.md)
+          if gh release view "$TAG" >/dev/null 2>&1; then
+            # 同 tag 重跑（补丁 / 重编）：Release 已存在 → 覆盖资产 + 刷新说明，
+            # 不再 `create`（那会因已存在而失败，把整条流水线在最后一步染红）。
+            gh release upload "$TAG" "${assets[@]}" --clobber
+            gh release edit "$TAG" "${flags[@]}"
+          else
+            gh release create "$TAG" "${assets[@]}" "${flags[@]}"
+          fi

packaging/README.md

@@ -55,11 +55,18 @@ python packaging/make_artifacts.py --no-smoke         # 跳过 ull --version 冒
 `.github/workflows/release.yml`：
 
 - 触发：`push` tag `v*`；`workflow_dispatch` 只构建不发布（验证矩阵仍编得过）。
+  `inputs.prerelease` **只在 tag ref 上 dispatch 才可达**——Actions 页面的 "Run workflow" 只能选分支，
+  要跑 tag 得 `gh workflow run release.yml --ref v0.1.0`。分支 ref 的 dispatch 与 push 一样被
+  `release` job 的 `if: github.ref_type == 'tag'` 挡在发布之外，所以「dispatch 只构建不发布」
+  与「dispatch 能关 pre-release」是两条互不冲突的规则。
 - 矩阵：`windows-latest`（MSVC + `-C target-feature=+crt-static`）、`ubuntu-22.04`（glibc 2.35 地板）、
   `macos-latest`（arm64）、`macos-15-intel`（Intel x64；`macos-13` 已下线，`macos-26-intel` 为更新替位）。
 - 每个槽位 `cargo build --release --locked` → `make_artifacts.py` → 归档内容自检 → 上传 artifact。
 - `release` job：下载全部 artifact → 重算一份全量 `SHA256SUMS.txt` → 用 `packaging/release-notes.md`
   模板渲染支持矩阵 → `gh release create`（**pre-release 默认开**，`workflow_dispatch` 可关）。
+- **同一 tag 重跑幂等**：`gh release view` 命中已存在的 Release 时改走 `gh release upload --clobber`
+  + `gh release edit`，覆盖资产与说明而不是再 `create`（`create` 遇已存在会失败，把流水线最后一步染红）。
+  pre-release 标记以首次创建为准，重跑不会翻转它——要改标记请手动 `gh release edit --prerelease / --prerelease=false`。
 
 Windows 为什么用 MSVC 静态 CRT 而不是本机这套 GNU 工具链：两者都属"标准工具链"（D21），
 但发布产物要**不依赖 VC++ 可再发行包**，`+crt-static` 把 CRT 静态链进 exe，Win10+ 的 UCRT 本身是
@@ -132,7 +139,11 @@ strip = "symbols"    # 剥符号表（GNU/MSVC 路径都生效）
 ```
 
 取舍：`lto = "fat"` + `codegen-units = 1` 让 release 链接明显变慢（本机全量 release 构建 10 分钟量级，
-见 §7.1），换来的是体积与启动时间；开发迭代走 `cargo build`（dev profile）完全不受影响。
+见 §7.1），换来的是体积与启动时间。变慢的根源在 `codegen-units = 1`：整个 crate 只切出一个 CGU，
+LTO 也就只有一个线程可跑（`fat` 本身只管"跨 crate 全量参与"，不等于单线程）。
+本地开发迭代走 `cargo build`（dev profile）不受影响，但 **`ci.yml` 每次 push/PR 都跑
+`cargo build --workspace --release`**，会实打实吃这份 fat LTO 的链接时间——CI 慢的一部分是 release
+档构建，不是测试本身。
 `panic = "abort"` 意味着 panic 不带 backtrace 栈展开——UI 层已用 `Result` 承接错误，
 `unwrap` 只出现在测试里，这是可接受的取舍。
 
@@ -152,7 +163,8 @@ strip = "symbols"    # 剥符号表（GNU/MSVC 路径都生效）
 
 `fat` 相对 `thin` 的实测差：GUI **−1,770,496 B（−10.8%）**，CLI **−1,415,168 B（−18.7%）**。
 一次全量 LTO 把跨 crate 的死代码与重复实例化一起消掉，收益远超常见印象里的"1~2%"；
-代价是 release 链接更慢（`fat` 是全局单线程 LTO），只影响发布/验收构建，日常 `cargo build` 走 dev profile 不受影响。
+代价是 release 链接更慢——慢在 `codegen-units = 1`（单 CGU → LTO 单线程），不是 `fat` 本身，
+且只影响发布/验收构建，日常 `cargo build` 走 dev profile 不受影响。
 
 体积构成（按依赖树判断）：Slint 运行时（femtovg + software 双渲染器 + winit/accesskit/托盘）+ rustls/reqwest
 + rig/rmcp/axum 是主要来源；`ull` 明显更小是 D18 纪律的直接结果（CLI 零 UI 框架依赖）。
@@ -177,6 +189,13 @@ unlucky-launcher-0.1.0-windows-x64.exe: OK
 
 版本守卫也实测过：`--version v9.9.9` 时脚本以 `tag/version mismatch: requested 9.9.9, Cargo.toml says 0.1.0` 失败退出（exit 1）。
 
+UNIX 归档的可复现性单独取证（本机 Windows 槽位只走裸 exe 分支，tar 路径要另测）：
+reviewer-packaging 在 M46 review 里连续调 `stage_archive()` 两次 → **两次 sha256 完全一致**
+`a99d6e9e727cd7e390434c566a15978451f340858fa89836e2f63790bbc392f8`；成员 `mtime=0`、
+`uid=gid=0`、`uname/gname` 为空、`mode` 0755（二进制）/ 0644（文本），gzip header 的 mtime 字段是
+`00000000`，归档内单顶层目录且含 `LICENSE`/`NOTICE`/`README.md`。
+即"同源构建 → 同 sha256"在 tar 路径上成立，不随打包时刻漂移（见 §1 的约定细节）。
+
 ### 7.4 运行时依赖证据（PE 导入表）
 
 `objdump -p target/release/unlucky-launcher.exe` 共 42 条 DLL 导入记录、33 个不同名字（大小写各记一次），全部是 Windows 自带：
@@ -186,7 +205,9 @@ uxtheme/uiautomationcore/opengl32/ws2_32/bcrypt/bcryptprimitives/ntdll` + 一组
 **没有** `VCRUNTIME140.dll` / `MSVCP140.dll` 这类 MSVC 可再发行包依赖，也没有 `libwinpthread-1.dll` /
 `libgcc_s_*.dll` 之类 MinGW 运行时 —— 即"拷走一个 exe 就能跑"（Win10+ 自带 UCRT）。
 CI 的 MSVC `+crt-static` 产物同理（静态 CRT）；`release.yml` 里用 `dumpbin -dependents` 把这条变成硬门禁，
-一旦静态 CRT 没生效（出现 VCRUNTIME/MSVCP/ucrtbase）就直接 fail，不允许"悄悄要用户装可再发行包"。
+两侧都 fail、没有降级分支：**出现 VCRUNTIME/MSVCP/ucrtbase 就 fail**，**找不到 dumpbin 同样 fail**
+（`windows-latest` 自带 VS 工具链，基本找得到；"找不到就跳过"等于让门禁在最需要它的时候失效）。
+总之不允许"悄悄要用户装可再发行包"。
 注意：本机只装了 GNU 工具链，MSVC 那个槽位的产物本身**没有在本机验证过**，由 CI 首跑验证。
 
 ## 8. 发行合规
@@ -200,7 +221,7 @@ CI 的 MSVC `+crt-static` 产物同理（静态 CRT）；`release.yml` 里用 `d
   Unicode-3.0 / CDLA-Permissive-2.0 / Slint-RF-2.0）。发布任务不新增任何依赖。
 - 发布产物不含游戏本体、不含 JRE、不含任何账号数据；`ull`/GUI 的数据目录在用户侧生成。
 
-## 9. 支持矩阵（对外口径，与 release-notes 模板一致）
+## 9. 支持矩阵（对外口径，与 release-notes 模板逐行一致）
 
 | 平台 | 级别 | 运行时要求 |
 |------|------|-----------|
@@ -209,7 +230,10 @@ CI 的 MSVC `+crt-static` 产物同理（静态 CRT）；`release.yml` 里用 `d
 | Linux x64 X11 | 一等 | glibc 2.35+、xkbcommon、fontconfig、libGL、xcb |
 | Linux x64 Wayland | 支持 | 上述 + wayland-client |
 | Windows 8.1/8/7 | 不支持 | 基线已上调（D21） |
-| Android Termux + X11 | 试验级（不承诺） | 仅 CLI |
+| Android Termux + X11 | 试验级（不承诺） | 仅 CLI（源码自建），GUI 未验证，不在本发布矩阵内 |
+
+`packaging/release-notes.md` 的 "Support matrix" 表与上表逐行对应（英文版，Termux 行同样标注
+experimental / not part of this release matrix）——改一边必须同步另一边，否则标题里的"一致"就是假话。
 
 ## 10. 已知边界 / 后续
 

packaging/release-notes.md

@@ -26,6 +26,7 @@ with the download on every platform.
 | Linux x64, X11 | first class | `libxkbcommon`, `fontconfig`, `libGL` (or software renderer), `libxcb` |
 | Linux x64, Wayland | supported | `wayland-client`, `libxkbcommon`, plus the X11 set for XWayland apps |
 | Windows 8.1/8/7 | unsupported | baseline was raised to Win10 (decision D21) |
+| Android — Termux + X11 | experimental, not promised | CLI only (build from source), GUI unverified; not part of this release matrix |
 
 ## Install