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。

.github/workflows/release-publish.yml

@@ -40,18 +40,21 @@ jobs:
       contents: write
     env:
       # ── 发布白名单：唯一决定「哪几个槽位进 Release」的开关（空格分隔，键同 matrix.slot）──
-      # **M142 起只有 `windows-x64`**：arm64 连试四轮未走通，而齐全性检查是「名单内少一档就 fail」——名字挂着
-      # arm64 就等于 x64 编成功也发不出去。故把它移出名单：它照留在矩阵里跑取证，**红了不挡发布**。
-      # （M164）**为什么现在还只有 x64**：arm64 五轮全红其实都红在一个误判的编译前体检步（见 release-build.yml
-      # 顶部那段），真正的 cargo/link 一次都没跑过；M164 把那个门禁拆了、判定权交回编译器，但「arm64 能不能编出
-      # PE」只能由**下一 tag 的 CI** 证明，本机没有 ARM64 真机/工具链证不了。在拿到那次绿之前把 arm64 写进来，
-      # 等于拿 x64 的发布去赌它 —— 同一个事故不演第二遍（tower M164 裁决）。
-      # **可逆，且只是一行**：那句 CI 真出包之后把键加回这一行（`"windows-x64 windows-arm64"`），齐全性检查与
-      # SHA256SUMS 自动跟着扩，再同步 README §1/§9 与 release-notes.md 两张表。
+      # **M184 起是 `windows-x64` + `linux-x64`**：`linux-x64` 已真机验过 —— release 产物在 Linux 真机（WSLg 真窗口）
+      # 渲出一帧、主题/后端日志齐全，并有一条同槽位的 xvfb 运行时门禁常驻在 `release-build.yml`（证据与实测输出见
+      # `packaging/docs/linux-evidence.md`）。进名单的代价是「每轮发版都得真出这个包」：齐全性检查是「名单内少一档就 fail」，
+      # 所以这条名单同时也是「linux-x64 构建红了就挡住整次发布」的闸 —— 与任务要求一致（声明为 ci 就得真能出包）。
+      # **`linux-arm64` 不在名单里，且这一轮刻意不放**：它只有构建证据，运行时完全没有证据（没有 ARM64 真机跑过一帧，
+      # 也没有 arm64 的 xvfb 冒烟）。解锁条件 = arm64 真机（或原生 runner）上真跑出一帧 + 主题日志 → 再把键加进这一行。
+      # 只加进矩阵不加进名单时，它的产物会被下面的裁剪步删掉，但守卫会先打 `::warning::` 明说「未发布、会被裁掉」，
+      # 不是静默丢弃（这条是任务里点名要验的反方向）。
+      # `windows-arm64` 同理仍不在名单（M142/M164：它的五轮红全红在误判的体检步，判定权已交回编译器，等下一 tag 的 CI 证）。
+      # **可逆，且只是一行**：真出包之后把键加进这一行（`"windows-x64 linux-x64 <新键>"`），齐全性检查与 SHA256SUMS
+      # 自动跟着扩，再同步 README §1/§9 与 release-notes.md 两张表。
       # 判据不再靠注释保证：`packaging/check_publish_slots.py`（下面第二个 step 跑它；PR 阶段由 release-guard.yml
       # 跑同一份脚本）两个方向都查——声明了缺产物 ⇒ `::error::` + exit 1；有产物但没声明 ⇒ `::warning::` 明说未发布。
-      # 四档 Linux/macOS 仍未验证，默认连构建都不跑（M139）。
-      PUBLISH_SLOTS: "windows-x64"
+      # macOS 两档仍未验证，默认连构建都不跑（M139）。
+      PUBLISH_SLOTS: "windows-x64 linux-x64"
     steps:
       - uses: actions/checkout@v4
 
@@ -87,7 +90,7 @@ jobs:
                 echo "publish: $base"
                 ;;
               *)
-                echo "drop:    $base（$platform_arch 不在发布白名单：四档未验证 / arm64 待下一 tag 验证；仍留在 dist-<slot> artifact 里取证）"
+                echo "drop:    $base（$platform_arch 不在发布白名单：macOS 两档未构建验证 / 两个 arm64 槽位待真机跑一帧；仍留在 dist-<slot> artifact 里取证）"
                 rm -f "$f"
                 ;;
             esac