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

packaging/README.md

@@ -55,7 +55,7 @@ Git Bash 下会静默落进 Docker VM（脚本内部用 `cygpath -m` 归一）
 
 | 文件 | 作用 | 行数上限 |
 |------|------|---------|
-| `packaging/README.md` | 本文：索引 + §11 / §12（契约入口；§1–§10 见 `docs/`） | ≤400 |
+| `packaging/README.md` | 本文：索引 + §11 / §12 / §13（契约入口；§1–§10 见 `docs/`） | ≤400 |
 | `packaging/docs/artifacts-and-version.md` | §1 产物矩阵 + §2 版本来源 | ≤400 |
 | `packaging/docs/build-and-ci.md` | §3 怎么构建（本地 / CI） | ≤400 |
 | `packaging/docs/runtime-deps.md` | §4 每平台运行时依赖 + §5 软渲染兜底 | ≤400 |
@@ -69,4 +69,30 @@ Git Bash 下会静默落进 Docker VM（脚本内部用 `cygpath -m` 归一）
 | `packaging/linux-check-docker.sh` | 本地复跑 `ci.yml` 的两条 ubuntu 门禁（clippy / test，Docker） | ≤400 |
 | `.github/workflows/release.yml` | tag 触发 → 选槽位（`plan`）→ 调下面两个可复用工作流 | ≤400 |
 | `.github/workflows/release-build.yml` | `workflow_call`：单槽位构建（体检 / cargo / 打包 / 上传 artifact） | ≤400 |
-| `.github/workflows/release-publish.yml` | `workflow_call`：发布（`PUBLISH_SLOTS` 裁剪 / SHA256SUMS / Release） | ≤400 |
+| `packaging/make_manifest.py` | 更新清单 `manifest.json` 的生成与自验（D50，见 §13） | ≤400 |
+| `packaging/tests/manifest.golden.json` | 清单 golden 样例：`make_manifest.py --self-test` 逐字节对拍 | ≤400 |
+| `.github/workflows/release-publish.yml` | `workflow_call`：发布（`PUBLISH_SLOTS` 裁剪 / SHA256SUMS / 清单 / Release） | ≤400 |
+
+## 13. 更新清单 `manifest.json`（D50）
+
+清单作为**固定文件名**的 Release 资产挂着；客户端按 `releases/latest/download/manifest.json` 取（D50）。
+字段形状的唯一权威是 `crates/core/src/update/manifest.rs` 的 `ReleaseManifest`（`deny_unknown_fields` +
+逐字段校验：semver、`size > 0`、摘要长度/字符集、`target`/`format` 取值表）——生成器只负责把那套形状填对。
+
+- **生成器**：`packaging/make_manifest.py`（零第三方依赖）。CI 在 `release-publish.yml` 里**重算
+  `SHA256SUMS.txt` 之后**调它，所以清单描述的是「真正要发的资产」，不是「构建出来的全部」。
+- **同源，不双写**：每个 `sha256` 直接读 `SHA256SUMS.txt`，`size` 取自同一批文件的 `stat()`；产物名里的版本段
+  必须等于 `--version`（tag 与 `Cargo.toml` 漂了就没有产物可对，当场失败）。`--self-test` 用
+  `packaging/tests/manifest.golden.json` 逐字节对拍，并跑 14 条负例证明严格解析不是摆设。
+- **只放启动器产物**：`ull` 不进清单。DTO 的 `Artifact` 没有角色字段，`Release::artifact_for()` 取「第一个
+  target 命中的产物」，把 CLI 并列写进去会让「该覆盖哪个文件」取决于数组顺序（`ull` 照旧进 `SHA256SUMS.txt`）。
+- **`url` 两种形态**：默认裸文件名（相对源根，`DirSource` 口径，本地/内网用）；CI 传 `--asset-base-url`
+  拼绝对地址，且**钉 tag 不钉 latest**——清单里每条都指向与它自报版本相符的字节。
+- `min_supported` / `notes` 只是**可填而不默认填**：前者是「收回老版本支持」的发布策略（未拍板，写错会强制升级），
+  后者在 Release 正文里已有，两处各写一份迟早漂。
+- 本地复跑：`python3 packaging/make_artifacts.py --manifest` → 与 CI 同一段代码，产出 `dist/manifest.json`。
+
+**未决（M151 报告里带利弊，供拍板）**：GitHub 的 `releases/latest/download/*` 只指向**非 prerelease** 的最新
+Release，而发布默认 `prerelease=true`。甲案 = 稳定发布时 dispatch `prerelease=false` 让 latest 生效（客户端地址不变）；
+乙案 = 客户端不用 latest、改按 tag 查 API（发布默认值不动，客户端多一次 API 调用）。`manifest.json` 已随每个
+Release 上传，两案都能用；在拍板前**不改发布默认值**。