feat(m190): 产物署名（PE VERSIONINFO）+ 清单 Ed25519 多签名与更新前验签

两件事：让「这是谁发的」在产物与清单上都留下可验证的痕迹。

① PE 版本资源（两个 bin）：`packaging/pe_version.rs` 是唯一口径（CompanyName
   「Unlucky Launcher Project」/ ProductName、FileDescription「Unlucky Launcher」/
   LegalCopyright「© 2026 … · Apache-2.0」/ 四段式版本号与 Cargo.toml 同源），被
   `crates/{cli,app-iced}/build.rs` 各 include 一次；非 windows 目标整段不执行。
   判据是读产物字节的 `packaging/check_pe_version.py`（CI 的 Windows 槽位）。

② 清单签名：`manifest.json` 旁边多一份 `manifest.json.sig`（分离签名，签的是清单**原始
   字节**），信封是 `{format, signatures:[{alg,key_id,sig,manifest_sha256}]}` —— 多签名数组，
   任意一条命中钉住的钥即放行（换钥窗口）。信任锚是 `crates/core/src/update/trust.rs`
   里的编译期公钥表（正式表为空 = fail-closed，测试钥只在 cfg(test)/update-test-source 里）。
   管线顺序改成「先验签、再解析」：`UpdateSource` 只交原文 + `.sig`，`verified_manifest`
   是唯一收口点，`Job::apply` 因此在取包**之前**就拒。新增五类错误分类
   （signature_missing / malformed / unknown_key / keyring_empty / invalid ），全部不可重试，
   CLI 的 hint 单独说人话。

③ Ed25519 验签自带实现（`update/ed25519/*`，零新依赖）：scope 不含 core 的 Cargo.toml，
   用 RFC 8032 §7.1 向量 + 可锻/小阶/非规范编码的拒绝用例钉住；签名侧是
   `packaging/sign_manifest.py`（纯 Python 参考实现，零 pip 依赖，`--self-test` 同向量）。

④ 守门：`release-publish.yml` 加签名步（`set +x`，只回显公钥；没 Secret / 钥没钉 / 签不上
   一律红 ⇒ 不出 Release）；`release-build.yml` 加 PE 资源读回；`release-guard.yml` 跑两个
   脚本的 `--self-test`。密钥纪律与轮换（旧钥签新钥）写在 `packaging/docs/signing.md`。

Cargo.lock：新增 winresource（build-dependency）与 toml 系；toml_datetime 1.1.2→1.1.3 是
toml 1.2.1 的硬要求（`cargo update --precise 1.1.2` 已实测被拒）。

.github/workflows/release-publish.yml

@@ -131,6 +131,32 @@ jobs:
             --asset-base-url "$RELEASE_BASE/$TAG" \
             --released-at "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
 
+      # （M190）清单签名：**签不上就不发版**。私钥只从仓库 Secret `ULL_MANIFEST_SIGNING_KEY` 进环境变量，
+      # 本步 `set +x` 且只回显**公钥**（日志里永远不出现私钥）。四条命令任一非零 ⇒ 本步红 ⇒ 不出 Release：
+      #   ① `--self-test`：RFC 8032 向量（签名脚本自己没坏）
+      #   ② `--check-pinned-keyring`：Secret 里的钥**必须**已在 `crates/core/src/update/trust.rs` 钉住
+      #      （签出一份客户端不认的清单，比不发版更糟）
+      #   ③ `--sign`：签的就是上一步落盘的 `dist/manifest.json` 原始字节，产出 `dist/manifest.json.sig`
+      # 红了的处置见 `packaging/docs/signing.md` §4 那张表（缺什么、怎么补，都写在脚本的 stderr 里）。
+      - name: 签更新清单（Ed25519；签不上就阻断发布）
+        shell: bash
+        env:
+          ULL_MANIFEST_SIGNING_KEY: ${{ secrets.ULL_MANIFEST_SIGNING_KEY }}
+        run: |
+          set -euo pipefail
+          set +x
+          PY=$(command -v python3 || command -v python)
+          if [ -z "$PY" ]; then echo "::error::找不到 python，签名步骤无法运行（签名门禁不降级）"; exit 1; fi
+          "$PY" packaging/sign_manifest.py --self-test
+          if [ -z "${ULL_MANIFEST_SIGNING_KEY:-}" ]; then
+            echo "::error::仓库 Secret ULL_MANIFEST_SIGNING_KEY 没配（或为空）：没有签名私钥就不发版。"
+            echo "::error::补法见 packaging/docs/signing.md §3：python3 packaging/sign_manifest.py --generate-key，把打印的 JSON 贴进 Secret、把 PinnedKey 那行贴进 crates/core/src/update/trust.rs"
+            exit 1
+          fi
+          "$PY" packaging/sign_manifest.py --check-pinned-keyring
+          "$PY" packaging/sign_manifest.py --sign dist/manifest.json
+          ls -l dist/manifest.json dist/manifest.json.sig
+
       - name: 生成 Release 说明（支持矩阵模板）
         shell: bash
         env:
@@ -172,7 +198,9 @@ jobs:
           echo "create_mark=(${create_mark[*]:-}) edit_mark=(${edit_mark[*]:-})"
           # Windows 单 exe 装不下 LICENSE/NOTICE/README.md，故三份与产物并列挂 Release（条款随包）；`ull` 是独立资产。
           # manifest.json 是更新清单（D50）：固定文件名，客户端问 `releases/latest/download/manifest.json`。
-          assets=(dist/unlucky-launcher_* dist/ull_* dist/manifest.json dist/SHA256SUMS.txt LICENSE NOTICE README.md)
+          # `manifest.json.sig` 必须与清单一起上传：客户端取清单后取它旁边的签名（`GitHubReleaseSource`
+          # 拼的地址是 `<产物根>/manifest.json.sig`），漏传等于让所有人都验签失败（M190）。
+          assets=(dist/unlucky-launcher_* dist/ull_* dist/manifest.json dist/manifest.json.sig 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