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-build.yml

@@ -6,6 +6,9 @@ name: Release / build（可复用）
 #   `matrix.rustflags` → `inputs.rustflags`。
 # **M164 改了两步**（只这两步）：① `Windows ARM64 工具链体检` → `工具链取证`（不再 exit 1，判定权交回编译器；
 # 理由见该步上方的长注释）；② `cargo build` 步给 arm64 槽位显式备齐 target / `LIB`+`INCLUDE` / arm64 `link.exe`。
+# **M184 加了一步**：`linux-x64` 的 xvfb 运行时冒烟（真渲一帧 + `[theme]` / `[backend] final` 日志断言 + 像素判定）——
+# 这一档进了 `PUBLISH_SLOTS`，「发出去的包真能跑」从此由 CI 每轮证明；判据只在 `linux-x64` 槽位上跑（arm64 没有
+# 对应的运行时证据，不给它加一条没验证过的门禁）。同一轮把 arm64 的失败收尾注解按槽位分支。
 # 矩阵**仍由调用方** `release.yml` 的 `plan` job 生成并在外层展开（矩阵不能带 `if`，`strategy` 可读 `needs`），
 # 本文件只跑**单个槽位**，不持有槽位表 —— 改槽位只改 `release.yml` 里那一处。
 # `env` 必须在被调方重复声明：**被调工作流不继承调用方的 workflow 级 `env`**（CARGO_TERM_COLOR / RUST_BACKTRACE
@@ -259,6 +262,49 @@ jobs:
             echo "::error::静态 CRT 未生效：exe 仍动态依赖 VC++ 可再发行包"; exit 1
           fi
 
+      # （M184）linux-x64 的**运行时门禁**：这一档已进 PUBLISH_SLOTS，所以「发出去的包真能开窗渲出一帧」得由 CI 每轮证明，
+      # 不能只靠一次性的本机验收（证据与实测输出见 `packaging/docs/linux-evidence.md`）。
+      # **只在 linux-x64 槽位上跑**：判据是按 x64 软渲染实测标定的；`linux-arm64` 上这条链一次都没验过（没有 arm64 的
+      # xvfb 证据），写成无条件的 `runner.os == 'Linux'` 就等于给一个没验证过的槽位加一条会红的判据——正是 M171 那个
+      # 「豁免行要单独落」的同类事故。宁可这条只在有证据的槽位上真跑。
+      - name: Linux x64 运行时冒烟（xvfb 真渲一帧 + 主题/后端日志断言）
+        if: inputs.slot == 'linux-x64'
+        shell: bash
+        env:
+          BUILD_DIR: ${{ inputs.build_dir }}
+        run: |
+          set -euo pipefail
+          sudo apt-get update
+          sudo apt-get install -y --no-install-recommends xvfb xauth \
+            libxkbcommon-x11-0 libx11-6 libxcursor1 libxrandr2 libxi6 libfontconfig1 fonts-dejavu-core
+          out="$RUNNER_TEMP/linux-smoke"
+          mkdir -p "$out/data"
+          log="$out/launcher.log"
+          # 退出码单独取：`tee` 之后的 `$?` 是 tee 的，管道里 cargo/launcher 的失败会被吞成 0。
+          set +e
+          xvfb-run -a --server-args="-screen 0 1280x1024x24" \
+            "$BUILD_DIR/unlucky-launcher-iced" --software-renderer \
+            --screenshot "$out/linux-x64-first-frame.png" --data-dir "$out/data" 2>&1 | tee "$log"
+          code=${PIPESTATUS[0]}
+          set -e
+          echo "launcher exit=$code"
+          # 两条日志断言（两行都是**恒开**的，不依赖 ULL_ACCEPTANCE）：
+          #   `[theme] source=…flavor=…follows_system=…` 证明主题是按预期来源定的（截图通道默认 Light），
+          #   `[backend] final=… result=started` 证明渲染后端真的起来了（而不是起来前就崩了）。
+          grep -q '^\[theme\] source=' "$log" || { echo "::error::缺少 [theme] 行（主题来源没打印）"; exit 1; }
+          grep -q '^\[backend\] final=.* result=started' "$log" || { echo "::error::缺少 [backend] final=… result=started（渲染后端没起来）"; exit 1; }
+          python3 packaging/check_screenshot.py "$out/linux-x64-first-frame.png" --json
+          ls -l "$out"
+          exit "$code"
+
+      - name: 上传 Linux x64 首帧图（失败也传，人眼复核用）
+        if: always() && inputs.slot == 'linux-x64'
+        uses: actions/upload-artifact@v4
+        with:
+          name: linux-x64-first-frame
+          path: ${{ runner.temp }}/linux-smoke/
+          if-no-files-found: warn
+
       - name: 打包（产物 + SHA256SUMS）
         shell: bash
         env:
@@ -310,7 +356,18 @@ jobs:
       # 「不挡发布」——只剩一句 `Process completed with exit code 1.` 的教训见上面那条体检步骤。
       # M164 起本槽位的红**只可能来自真实构建链路**（体检已降级为取证、永不 exit 1），所以这条注解同时也是
       # 「arm64 到底能不能编出来」的答案所在：红了就把上面的编译器/链接器原文当根因，别再回去改体检。
+      # M184：Linux arm64 进来（它现在是 `mode: ci`，tag 推送默认就编），措辞按槽位分支 —— 两个 arm64 都**不在**发布名单里，
+      # 但理由不同：windows-arm64 等「能不能出 PE」的答案，linux-arm64 等「真机跑不跑得起来」的答案。
       - name: arm64 失败收尾注解（红不挡发布）
-        if: failure() && inputs.slot == 'windows-arm64'
+        if: failure() && (inputs.slot == 'windows-arm64' || inputs.slot == 'linux-arm64')
         shell: bash
-        run: echo "::error::[arm64] 本槽位已红，失败步骤见本 job 的步骤名（M164 起只会是 cargo build / 链接 / 导入表门禁 / 打包，体检步不再判红）；PUBLISH_SLOTS 当前只有 windows-x64 ⇒ 本次 Release 仍照发 x64，arm64 产物不进 Release"
+        env:
+          SLOT: ${{ inputs.slot }}
+        run: |
+          set -euo pipefail
+          if [ "$SLOT" = "linux-arm64" ]; then
+            reason="本槽位只有构建证据、运行时完全未验（没有 ARM64 真机跑过一帧）"
+          else
+            reason="失败步骤见本 job 的步骤名（M164 起只会是 cargo build / 链接 / 导入表门禁 / 打包，体检步不再判红）"
+          fi
+          echo "::error::[$SLOT] 本槽位已红：$reason。PUBLISH_SLOTS 当前是 windows-x64 + linux-x64 ⇒ 本次 Release 仍照发那两档，$SLOT 的产物不进 Release"