ci(m184): linux-x64 进发布名单，两档 Linux 转 mode=ci，arm64 只构建不发布

发布流水线默认从 2 个槽位变 4 个：`linux-x64`（ubuntu-22.04）与 `linux-arm64`
（ubuntu-22.04-arm）的 mode 由 probe 改 ci，tag 推送默认就编。

构建 ≠ 发布仍由 `PUBLISH_SLOTS` 决定，本轮只加 `linux-x64`：
- `linux-x64` 有运行时证据 —— release 产物在 Linux 真机（Ubuntu 22.04 + WSLg 真窗口）
  渲出一帧、[theme]/[backend] final 日志齐全、像素判定通过，真窗口 1180x760 从 Windows
  侧截屏可见；`release-build.yml` 另加一条**同槽位**的 xvfb 运行时门禁（只在
  `inputs.slot == 'linux-x64'` 上跑，不给没验过的 arm64 造红）。
- `linux-arm64` 只有构建证据、运行时零证据，产物照出 artifact 取证但不发布；解锁条件
  （真机渲出一帧 + 主题日志）写进 release-notes 与 §9。

守卫跟着扩（`packaging/check_publish_slots.py`）：
- 自测从 8 条扩到 11 条，新增「声明的 linux-x64 构建红了 ⇒ 必须红（挡住发布）」、
  「linux-arm64 有产物但没声明 ⇒ 只警告」、「提前把 linux-arm64 写进名单 ⇒ 缺产物必红」；
- probe 档样例从 linux-x64 换成仍是 probe 的 macos-arm64（否则该用例会从「必须红」
  变成「本来该绿」）；
- 新增「mode=ci 却本次没产物 ⇒ ::warning::」：红一档不能只表现为表里少一行。

文档矩阵同步（release-notes §Downloads/§Support matrix、compliance §9/§10、
artifacts §1、build-and-ci §3、README ×2），两份文档都把 Linux 写成
「已构建并发布（x64）/ 已构建未发布（arm64）」，并把新发现写实：Linux 上整窗透明
与圆角没有代码路径（hwnd=none / corner=policy=system），不是「未验」；Linux 上
`ull update apply` 会拒绝 portable-zip（清单里现在有 linux-x64 产物）。

证据账（含实测输出、CI 增量估算、未验清单）：packaging/docs/linux-evidence.md。

packaging/docs/compliance-support-boundaries.md

@@ -21,25 +21,32 @@
 | 平台 | 本版发布 | 级别 | 运行时要求 |
 |------|---------|------|-----------|
 | Windows 10/11 x64 | ✅ | 一等 | 无（UCRT 系统自带） |
+| Linux x64 X11 | ✅ | 一等 | glibc 2.35+（`ubuntu-22.04` 原生构建即地板）、xkbcommon、fontconfig、libGL（或软渲染）、xcb |
+| Linux x64 Wayland | ✅（同一归档；**Wayland 路径未验**） | 支持 | 上述 + wayland-client（XWayland 应用仍需 X11 那套） |
 | Windows 11 ARM64 | ❌ 不发布（构建取证中） | 一等（启动器产物） | 无额外库；启动器原生运行，游戏本体走系统 x64 模拟层 + x64 JDK |
+| Linux arm64 | ❌ 已构建、不发布（**运行时零证据**） | 一等（未真机验证） | glibc 2.35+（`ubuntu-22.04-arm` 原生构建，**与 x64 同地板**）、xkbcommon、fontconfig、libGL、xcb / 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 均需源码自建；GUI 已在单机真机验证两条路径各一次（CPU 软渲染 + 自编 Mesa/turnip GPU 加速，配方见 `packaging/docs/termux-glibc-build.md`、证据见 `README.termux.md`），不在本发布矩阵内 |
 
 `packaging/release-notes.md` 的 "Support matrix" 表与上表逐行对应（英文版同样带 published / not
 published 一列，Termux 行标注 experimental）——改一边必须同步另一边，否则标题里的"一致"就是假话。
 
-两个 arm64 槽位都是**正式矩阵槽位**（不是 Termux 那种源码自建旁路），但本版两个都**不发布**：`windows-arm64` 照构建取证
-（红了不挡 x64 发布），`linux-arm64` 连构建都不跑；发布开关是 `release-publish.yml` 的 `PUBLISH_SLOTS`（当前只有 `windows-x64`）。
+**M184 的翻牌（Linux x64 进发布名单，arm64 只构建）**：发布开关仍是 `release-publish.yml` 的 `PUBLISH_SLOTS`，
+现在是 `windows-x64 linux-x64`；`release.yml` 槽位表里 `linux-x64` 与 `linux-arm64` 都是 `mode: ci`（tag 推送默认就编）。
+两档的唯一差别是**运行时证据**：
 
-（M164）`windows-arm64` 为什么还没进名单：它 v0.2.1~v0.2.3 的红**全部**红在一个编译前体检步（`find` 猜 SDK 的
+- `linux-x64` 有：release 产物在 Linux 真机（Ubuntu 22.04 + WSLg 真窗口）渲出一帧、`[theme]` 与
+  `[backend] final=… result=started` 两行齐全、像素判定通过；`release-build.yml` 里还有一条**同槽位**的 xvfb
+  运行时门禁，每轮发布都重跑（证据与实测输出：`packaging/docs/linux-evidence.md`）。
+- `linux-arm64` 没有：没有任何 ARM64 机器跑过它一帧，也没有 arm64 的 xvfb 冒烟。**解锁条件 = 真机（或原生
+  ARM64 runner）上真跑出一帧 + 主题日志**，之后才把键加进 `PUBLISH_SLOTS`。构建绿了不算解锁，别拿没跑过的包发人。
+
+`windows-arm64` 为什么还没进名单（M164 遗留）：它 v0.2.1~v0.2.3 的红**全部**红在一个编译前体检步（`find` 猜 SDK 的
 `um/arm64/kernel32.lib`），`cargo build` 一次都没跑过；M164 把那个门禁降级为只取证、判定权交回编译器，但「能不能
-出 PE」只能由**下一 tag 的 CI** 证明。名单 ⇄ 产物的两个方向现在都有守卫（`packaging/check_publish_slots.py`）：
-声明了缺产物 ⇒ 红，有产物没声明 ⇒ `::warning::` 明说未发布 —— 所以那次 CI 真出包之后，翻一行名单即可。
+出 PE」只能由**下一 tag 的 CI** 证明。名单 ⇄ 产物的两个方向都有守卫（`packaging/check_publish_slots.py`）：
+声明了缺产物 ⇒ 红（这正是「声明为 ci 的槽位构建红了就挡住发布」那条闸），有产物没声明 ⇒ `::warning::` 明说未发布，
+`mode: ci` 却本次没产物 ⇒ 也打 `::warning::`（红了要看得见）—— 所以那次 CI 真出包之后，翻一行名单即可。
 
 ## 10. 已知边界 / 后续
 
@@ -57,3 +64,9 @@ published 一列，Termux 行标注 experimental）——改一边必须同步
    `windows-arm64` / `linux-arm64` 的**真实产物只能由 CI 出**（前者靠 `dumpbin -dependents` 的静态 CRT
    门禁 + 架构校验，后者在 `ubuntu-22.04-arm` 上真跑 `ull --version` 冒烟）；本机能做且已做的是脚本层
    取证（§7.5：宿主判定注入、可执行文件头识别、把真 exe 的 PE 机器码改成 ARM64 当 stub 走完全流程）。
+8. **Linux 上自更新只"能查不能装"**（M184 发布 Linux x64 之后才有意义）：清单现在会带 `linux-x64` 的
+   `portable-zip` 产物，而 `ull update apply` 只做便携单文件 `.exe` 的自替换
+   （`crates/core/src/update/job.rs::ensure_self_replaceable`）——Linux 上它会带具名原因**拒绝**
+   （"发布里的 linux-x64 产物是 portable-zip 形态，不能原地替换启动器 … 压缩包请解压后再用"），
+   不会半装坏。Linux 的更新方式仍是「下载新归档覆盖旧副本」。真要做 Linux 自更新（换目录里的文件再重启）
+   是另一件事，未规划。