feat(packaging): M151 发布流水线生成更新清单 manifest.json（D50）

清单挂 GitHub Release 资产，固定文件名 manifest.json（D50）。字段形状的权威是 M146 的
crates/core/src/update/manifest.rs（ReleaseManifest，deny_unknown_fields + 逐字段校验），
生成器只负责把那套形状填对，不另立 schema。

同源，不双写：packaging/make_manifest.py 的每个 sha256 直接读 Release 自己的
SHA256SUMS.txt，size 取自同一批文件的 stat()；产物名里的版本段必须等于 --version，
tag 与 Cargo.toml 漂了就没有产物可对，当场失败。CI 在「裁剪发布白名单后重算
SHA256SUMS」之后调它，所以清单描述的是真正要发的资产，不是构建出来的全部。
make_artifacts.py 只加 --manifest 开关，用子进程调同一份脚本（本地跑也产出
manifest.json），本文件继续是产物命名的唯一真相源。

只放启动器产物：DTO 的 Artifact 没有角色字段，Release::artifact_for() 取第一个
target 命中的产物，把 ull 并列写进去会让「覆盖哪个文件」取决于数组顺序；ull 照旧进
SHA256SUMS.txt 与 Release。

url 两种形态：默认裸文件名（DirSource 口径，本地/内网用）；CI 传 --asset-base-url
拼绝对地址并钉 tag（不是 latest），清单里每条都指向与它自报版本相符的字节。

自验：--self-test 用 packaging/tests/manifest.golden.json 逐字节对拍（覆盖裸 exe 与
tar.gz 两种形态，并钉住「ull 不进清单」），再跑 14 条负例证明严格解析不是摆设；
发布步会先跑它再产文件。真 DTO 对拍已在本机用 M146 的 ReleaseManifest 实测：
golden 解析通过（2 个产物、min_supported、force 均正确落位），14 条篡改全部被拒。

未决（报告带利弊，未自行改发布默认值）：releases/latest/download/* 只指向非 prerelease
的最新 Release，而发布默认 prerelease=true。

Refs: D50, M146

.github/workflows/release-publish.yml

@@ -94,6 +94,27 @@ jobs:
           sha256sum -c SHA256SUMS.txt
           cat SHA256SUMS.txt
 
+      - name: 生成更新清单 manifest.json（D50：固定名挂 Release 资产）
+        shell: bash
+        env:
+          TAG: ${{ github.ref_name }}
+          RELEASE_BASE: ${{ github.server_url }}/${{ github.repository }}/releases/download
+        run: |
+          set -euo pipefail
+          # 先自验再产文件：golden 对拍 + 「DTO 严格解析」镜像（未知字段 / 摘要长度 / size=0 / 版本重复
+          # 这些在发布步当场炸，而不是变成用户机器上的「查不到更新」）。零第三方依赖，毫秒级。
+          python3 packaging/make_manifest.py --self-test
+          # 事实来源是上一步**重算**出来的 dist/SHA256SUMS.txt：清单不另算一份摘要，两者不可能不一致。
+          # url 钉死 tag（不是 latest）：清单里每条都指向与它自报版本相符的字节。
+          # min_supported / notes 刻意先不写：前者是「收回老版本支持」的发布策略（未拍板，写错会强制升级），
+          # 后者在 Release 正文里已有，两处各写一份迟早漂。
+          python3 packaging/make_manifest.py \
+            --dist dist \
+            --version "$TAG" \
+            --channel stable \
+            --asset-base-url "$RELEASE_BASE/$TAG" \
+            --released-at "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
+
       - name: 生成 Release 说明（支持矩阵模板）
         shell: bash
         env:
@@ -141,7 +162,12 @@ jobs:
               ;;
           esac
           # Windows 单 exe 装不下 LICENSE/NOTICE/README.md，故三份与产物并列挂 Release（条款随包）；`ull` 是独立资产。
-          assets=(dist/unlucky-launcher_* dist/ull_* dist/SHA256SUMS.txt LICENSE NOTICE README.md)
+          # manifest.json 是更新清单（D50）：固定文件名，客户端问 `releases/latest/download/manifest.json`。
+          # ⚠️ 未决（M151 报告带利弊，未自行改默认值）：GitHub 的 `releases/latest/download/*` 只指向**非
+          # prerelease** 的最新 Release，而下面首次 create 默认勾 `--prerelease`。矛盾的两个方案——
+          #   甲：稳定发布时显式 dispatch `prerelease=false`（latest 随之生效，客户端地址不变）；
+          #   乙：客户端不用 latest，改按 tag 查 API 再取 assets（发布默认值不用动，客户端多一次 API 调用）。
+          assets=(dist/unlucky-launcher_* dist/ull_* dist/manifest.json 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