ci(release): M139 发布 CI 只跑两个 Windows 槽位，整表六槽位改为手动取证

build 矩阵从六个槽位裁到 windows-x64 / windows-arm64 两个：
- 矩阵改由新增的 `plan` job 生成（`fromJSON(needs.plan.outputs.matrix)`），槽位表只在该
  job 里有一份，`mode: ci` 默认编、`mode: probe` 只有 `all_slots=true` 才编；
- `workflow_dispatch` 新增 `all_slots` 布尔输入（默认 false = 只跑 Windows），
  Linux/macOS 四档保留完整定义与打开办法（改 mode 一行），取证能力没删；
- `PUBLISH_SLOTS` 不变（两个 Windows 槽位）；齐全性检查仍按下载下来的产物判，
  白名单槽位没编/编挂就 fail，不会因矩阵变小而永远过；
- packaging/README.md §1/§3/§4/§9 与 release-notes.md 的 Downloads / Support matrix
  同步成「四档默认不构建」，不留「六槽位都构建」的旧说法。

packaging/README.md

@@ -10,15 +10,17 @@
 |------|---------|-----------|------|---------|
 | `windows-x64` | ✅ 发布 | `unlucky-launcher_<ver>_windows_x64.exe` | **裸 exe**（双击即用） | exe 单文件；三份合规文本作为并列 Release 资产 |
 | `windows-arm64` | ✅ 发布 | `unlucky-launcher_<ver>_windows_arm64.exe` | **裸 exe**（同 x64 策略） | 同上；在 x64 宿主上交叉编译到 `aarch64-pc-windows-msvc` |
-| `linux-x64` | ❌ 只构建取证 | `unlucky-launcher_<ver>_linux_x64.tar.gz` | 单二进制归档 | `unlucky-launcher` + `LICENSE` + `NOTICE` + `README.md` |
-| `linux-arm64` | ❌ 只构建取证 | `unlucky-launcher_<ver>_linux_arm64.tar.gz` | 单二进制归档（原生 ARM64 runner 构建） | 同上 |
-| `macos-arm64` | ❌ 只构建取证 | `unlucky-launcher_<ver>_macos_arm64.tar.gz` | 单二进制归档 | 同上 |
-| `macos-x64` | ❌ 只构建取证 | `unlucky-launcher_<ver>_macos_x64.tar.gz` | 单二进制归档 | 同上 |
+| `linux-x64` | ❌ 不构建（未验证） | `unlucky-launcher_<ver>_linux_x64.tar.gz` | 单二进制归档 | `unlucky-launcher` + `LICENSE` + `NOTICE` + `README.md` |
+| `linux-arm64` | ❌ 不构建（未验证） | `unlucky-launcher_<ver>_linux_arm64.tar.gz` | 单二进制归档（原生 ARM64 runner 构建） | 同上 |
+| `macos-arm64` | ❌ 不构建（未验证） | `unlucky-launcher_<ver>_macos_arm64.tar.gz` | 单二进制归档 | 同上 |
+| `macos-x64` | ❌ 不构建（未验证） | `unlucky-launcher_<ver>_macos_x64.tar.gz` | 单二进制归档 | 同上 |
 | 每槽位 | 随所属槽位 | `ull_<ver>_<平台>_<架构>[.exe]` | **裸 CLI 文件**（独立资产，不进 tar.gz） | 零 UI 依赖的 `ull` 本体，进同一份 `SHA256SUMS.txt` |
 | 全平台 | 仅已发布资产 | `SHA256SUMS.txt` | 校验清单 | 每行 `<sha256>␠␠<文件名>`（`sha256sum -c` 可直吃） |
 
 约定细节：
 
+- **「不构建」= CI 默认根本不跑**（M139）：那四档未验证，产物不给用户、构建配额也不花；要整表六槽位取证走
+  `gh workflow run release.yml -f all_slots=true`（§3）。发布白名单仍只有两个 Windows 槽位。
 - **产物命名**：`<名字>_<版本号>_<平台>_<架构>`，下划线分段、**不带实现细节字样**（不出现 `iced`）；真相源是 `make_artifacts.py::asset_stem()`。
 - **"单文件"指可执行文件本身零运行时依赖**（无 WebView、无 JRE、无 sidecar、无 DLL 旁挂）；归档里的三份合规文本是许可义务、不是运行时依赖，Windows 因为"一个 exe 装不下文本"，
   把 `LICENSE` / `NOTICE` / `README.md` 作为 Release 的并列资产分发，条款同样随下载走。
@@ -74,43 +76,42 @@ python packaging/make_artifacts.py --slot windows-arm64 \
 
 `--slot` 与宿主槽位不一致时，`ull --version` 冒烟会**自动跳过并打印原因**（arm64 产物在 x64
 宿主机上根本执行不了；拿"跳过"当通过是假证据，所以跳过永远带原因）——那条路径的验证只能落在
-CI 真机上：`windows-arm64` 由 cross 构建产物 + M50 的 dumpbin 导入表门禁覆盖，`linux-arm64`
-由 `ubuntu-22.04-arm` 原生 runner 上真跑冒烟覆盖。
+CI 真机上：`windows-arm64` 由 cross 构建产物 + M50 的 dumpbin 导入表门禁覆盖；`linux-arm64` 的同类
+冒烟只在 `all_slots=true` 的取证跑里出现（`ubuntu-22.04-arm` 原生 runner 上真跑 `ull --version`）。
 
-### CI（四平台六槽位矩阵）
+### CI（默认只跑两个 Windows 槽位；`all_slots=true` 才整表六槽位）
 
 `.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.2.1`。分支 ref 的 dispatch 与 push 一样被
-  `release` job 的 `if: github.ref_type == 'tag'` 挡在发布之外，所以「dispatch 只构建不发布」
-  与「dispatch 能关 pre-release」是两条互不冲突的规则。
-- 矩阵（六槽位；`matrix.build_dir` 参数化产物根，脚本不再假设产物一定在 `target/release`）：
-  `windows-latest` x64（MSVC + `-C target-feature=+crt-static`）、`windows-latest` **交叉编译**到
-  `aarch64-pc-windows-msvc`（产物在 `target/aarch64-pc-windows-msvc/release`）、`ubuntu-22.04`
-  （glibc 2.35 地板）、`ubuntu-22.04-arm`（原生 ARM64 runner，**与 x64 同 2.35 地板**）、`macos-latest`（arm64）、
-  `macos-15-intel`（Intel x64；`macos-13` 已下线，`macos-26-intel` 为更新替位）。
+- 触发：`push` tag `v*`；`workflow_dispatch` 只构建不发布，且多一个 `all_slots` 开关（**默认 false =
+  只跑两个 Windows 槽位**，true = 整表六槽位都编一遍取证）。`inputs.prerelease` **只在 tag ref 上 dispatch
+  才可达**——Actions 页面的 "Run workflow" 只能选分支，要跑 tag 得 `gh workflow run release.yml --ref v0.2.1`。
+  分支 ref 的 dispatch 与 push 一样被 `release` job 的 `if: github.ref_type == 'tag'` 挡在发布之外，所以
+  「dispatch 只构建不发布」与「dispatch 能关 pre-release」是两条互不冲突的规则。
+- 矩阵**由 `plan` job 按 `all_slots` 生成**（`matrix: ${{ fromJSON(needs.plan.outputs.matrix) }}`：矩阵本身
+  不能带 `if`，而 `strategy` 可读 `needs`），槽位表只在该 job 里有一份：`windows-latest` x64（MSVC +
+  `-C target-feature=+crt-static`，产物在 `target/release`）与 `windows-latest` **交叉编译**到
+  `aarch64-pc-windows-msvc`（产物在 `target/aarch64-pc-windows-msvc/release`）标 `mode: ci`（默认编）；
+  `ubuntu-22.04`（glibc 2.35 地板）/ `ubuntu-22.04-arm`（原生 ARM64，同地板）/ `macos-latest` /
+  `macos-15-intel` 标 `mode: probe`——**未验证，默认一个都不编**，只有 `all_slots=true` 才进矩阵。
 - 每个槽位 `cargo build --release --locked`（交叉槽位多两步：`rustup target add` + ARM64 库体检
   ——查 VC 的 `lib/arm64/libcmt.lib`（`+crt-static` 靠它）与 SDK 的 `um/arm64/kernel32.lib`，
   缺了直接给出"给 VS 加 `VC.Tools.ARM64` 或改用原生 `windows-11-arm`"的可执行提示）→
   `make_artifacts.py --slot … --build-dir …` → 归档内容自检 → 上传 artifact。
-- **发布白名单（`PUBLISH_SLOTS`，唯一开关）**：六槽位一律构建取证，只有白名单里的槽位进 Release 与
-  `SHA256SUMS.txt`——当前 = `windows-x64 windows-arm64`；Linux x64/arm64、macOS arm64/x64 四档**从未真构建
-  成功过一次、也没在真机跑过**，不推给用户（产物留在本次运行的 `dist-<slot>` artifact 里取证，它们红了也
-  不连坐 Windows 发布）。手动入口 `workflow_dispatch`（分支 ref）把六槽位整体编一遍、不发布；将来某槽位
-  真机验证通过，把它的键加进这一行即打开（齐全性检查与 SHA256SUMS 自动跟着扩），并同步 §1/§9 与本文件。
+- **发布白名单（`PUBLISH_SLOTS`，唯一开关）**：默认只构建两个 Windows 槽位，只有白名单里的槽位进 Release 与
+  `SHA256SUMS.txt`——当前 = `windows-x64 windows-arm64`；四档未验证的（默认连构建都不跑）不推给用户。
+  将来某槽位真机验证通过：`plan` 槽位表里把它的 `mode` 从 `probe` 改成 `ci`、把键加进这一行（齐全性检查
+  与 `SHA256SUMS` 自动跟着扩）、再同步 §1/§9 与 `release-notes.md`——三处缺一即是假话。
 - `release` job：下载全部 artifact → **按白名单裁剪** → 重算 `SHA256SUMS.txt` → 用 `packaging/release-notes.md`
   模板渲染支持矩阵 → `gh release create`（**pre-release 默认开**：首建时 `push` 触发按 pre-release，`workflow_dispatch` 可关）。
 - **同一 tag 重跑幂等**：`gh release view` 命中已存在的 Release 时改走 `gh release upload --clobber`
   + `gh release edit`，覆盖资产与说明而不是再 `create`（`create` 遇已存在会失败，把流水线最后一步染红）。
 - **pre-release 标记只按显式输入断言**：`gh release edit` 分支在默认重跑（`push` 触发的 Re-run，
   `inputs.prerelease` 为空）时**不传** `--prerelease`，所以重跑**不会**翻转标记；只有 tag ref 上的
-  `workflow_dispatch` 显式给了输入才断言——`prerelease=true` → `--prerelease`，`prerelease=false` →
-  `--prerelease=false`。要改标记两条路等价且互不打架：① 走流水线
-  `gh workflow run release.yml --ref v0.2.1 -f prerelease=false`（会落到 edit 分支显式断言）
-  ② 直接 `gh release edit <tag> --prerelease=false`（不经流水线；后续默认重跑不碰该标记，
-  不会被翻回去）。首建（`create`）仍保持「pre-release 默认开」的老契约，空输入按 `true` 处理。
+  `workflow_dispatch` 显式给了输入才断言（`prerelease=true` → `--prerelease`，`false` → `--prerelease=false`）。
+  要改标记两条路等价且互不打架：① 走流水线 `gh workflow run release.yml --ref v0.2.1 -f prerelease=false`
+  （会落到 edit 分支显式断言）② 直接 `gh release edit <tag> --prerelease=false`（不经流水线；后续默认重跑
+  不碰该标记，不会被翻回去）。首建（`create`）仍保持「pre-release 默认开」的老契约，空输入按 `true` 处理。
 
 Windows 为什么用 MSVC 静态 CRT 而不是本机这套 GNU 工具链：两者都属"标准工具链"（D21），
 但发布产物要**不依赖 VC++ 可再发行包**，`+crt-static` 把 CRT 静态链进 exe，Win10+ 的 UCRT 本身是
@@ -149,7 +150,7 @@ Windows ARM64 原生库（Mojang/LWJGL 只发 x64/x86），实际游玩仍走系
 
 | 依赖 | 说明 |
 |------|------|
-| glibc ≥ 2.35 | 由 `ubuntu-22.04` 构建决定；更老的发行版请自行重建或等 musl 版 |
+| glibc ≥ 2.35 | 由 `ubuntu-22.04` 构建决定（该槽位默认不编，`all_slots=true` 取证跑才有产物）；更老的发行版请自行重建或等 musl 版 |
 | `libxkbcommon.so.0` | winit 键盘处理 |
 | `libfontconfig.so.1` + `libfreetype.so.6` | 文本渲染 |
 | `libGL.so.1` / `libEGL.so.1` | Slint 版：femtovg 的 GL 渲染；iced 版：wgpu 的 GL/EGL 后端（**推断，未实测**）。两者缺失都退到 CPU 软渲染（tiny-skia） |
@@ -166,7 +167,7 @@ arm64 侧同理（同一份依赖树；历史口径里的「winit + femtovg」
 ### Linux arm64（aarch64）
 
 依赖与 x64 完全同一套（`libxkbcommon` / `fontconfig` / `libGL` / `libxcb` / `libwayland-client`），
-**glibc 地板也相同**：arm64 槽位跑在原生 `ubuntu-22.04-arm` runner 上，地板 = **2.35**，与 x64
+**glibc 地板也相同**：arm64 槽位跑在原生 `ubuntu-22.04-arm` runner 上（默认矩阵不编它，只有 `all_slots=true` 取证跑才出产物），地板 = **2.35**，与 x64
 用的 `ubuntu-22.04` 一致。选 22.04 而不是 24.04 就是为了这个地板——24.04 的 glibc 更高，会把
 Debian 12（2.36）、Raspberry Pi OS Bookworm（2.36）这些实际在跑的 ARM 发行版挡在门外。
 要抬地板（例如将来 ARM 生态整体上移）换 `release.yml` 里那个槽位的 `os` 即可，脚本与产物名都不用动；
@@ -334,19 +335,19 @@ runner 上的真跑（本机连 `raw.githubusercontent.com` 都解析不了，
 |------|---------|------|-----------|
 | Windows 10/11 x64 | ✅ | 一等 | 无（UCRT 系统自带） |
 | Windows 11 ARM64 | ✅ | 一等（启动器产物） | 无额外库；启动器原生运行，游戏本体走系统 x64 模拟层 + x64 JDK |
-| macOS 12+（arm64 / x64） | ❌ 只构建取证 | 一等（未真机验证） | 无第三方库；未签名需去 quarantine |
-| Linux x64 X11 | ❌ 只构建取证 | 一等（未真机验证） | glibc 2.35+、xkbcommon、fontconfig、libGL、xcb |
-| Linux x64 Wayland | ❌ 只构建取证 | 支持 | 上述 + wayland-client |
-| Linux arm64 X11 | ❌ 只构建取证 | 一等（未真机验证） | glibc 2.35+（`ubuntu-22.04-arm` 原生构建，**与 x64 同地板**）、xkbcommon、fontconfig、libGL、xcb |
-| Linux arm64 Wayland | ❌ 只构建取证 | 支持 | 上述 + wayland-client |
+| macOS 12+（arm64 / x64） | ❌ 不构建 | 一等（未真机验证） | 无第三方库；未签名需去 quarantine |
+| Linux x64 X11 | ❌ 不构建 | 一等（未真机验证） | glibc 2.35+、xkbcommon、fontconfig、libGL、xcb |
+| Linux x64 Wayland | ❌ 不构建 | 支持 | 上述 + wayland-client |
+| Linux arm64 X11 | ❌ 不构建 | 一等（未真机验证） | glibc 2.35+（`ubuntu-22.04-arm` 原生构建，**与 x64 同地板**）、xkbcommon、fontconfig、libGL、xcb |
+| Linux arm64 Wayland | ❌ 不构建 | 支持 | 上述 + wayland-client |
 | Windows 8.1/8/7 | — | 不支持 | 基线已上调（D21） |
 | Android Termux + X11 | — | 试验级（不承诺） | 仅 CLI（源码自建），GUI 未验证，不在本发布矩阵内 |
 
 `packaging/release-notes.md` 的 "Support matrix" 表与上表逐行对应（英文版同样带 published / not
 published 一列，Termux 行标注 experimental）——改一边必须同步另一边，否则标题里的"一致"就是假话。
 
-两个 arm64 槽位都是**正式矩阵槽位**（不是 Termux 那种源码自建旁路），但**本版只有 `windows-arm64`
-发布**：`linux-arm64` 由原生 runner 编、尚未真机验证，发布开关就是 `release.yml` 的 `PUBLISH_SLOTS`。
+两个 arm64 槽位都是**正式矩阵槽位**（不是 Termux 那种源码自建旁路），但本版只有 `windows-arm64` 发布；`linux-arm64` 连构建都不跑
+（默认矩阵只有两个 Windows 槽位），发布开关是 `release.yml` 的 `PUBLISH_SLOTS`，取证入口是 `all_slots=true`。
 
 ## 10. 已知边界 / 后续