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` 已实测被拒）。

packaging/README.md

@@ -146,3 +146,17 @@ Git Bash 下会静默落进 Docker VM（脚本内部用 `cygpath -m` 归一）
   `ci.yml` 的 `update-e2e` job（**只在 Windows**：夹具的「真形状」是 Windows 裸 `.exe` +
   `portable-exe`；Linux/macOS 的真实产物是 `.tar.gz` + `portable-zip`，在本模块会被直接拒）。
   **不验**真 GitHub 下载、GUI 点击与重启替换（需人工）。
+
+## 14. 产物署名与清单签名（M190）
+
+这一节只放「去哪看」的三句话，手册本体在 **`packaging/docs/signing.md`**：
+
+- **PE 版本资源**（Windows「属性 → 详细信息」里的发布者/产品/版权/四段式版本）：口径唯一来源
+  `packaging/pe_version.rs`，被 `crates/cli/build.rs` 与 `crates/app-iced/build.rs` 各 `include!` 一次；
+  判据是**读产物字节**的 `packaging/check_pe_version.py`（CI：`release-build.yml` 的 Windows 槽位）。
+- **清单签名**：`manifest.json.sig` 与 `manifest.json` 并列上传，是分离的 Ed25519 签名文件（签的是清单
+  的**原始字节**，不是某个规范化后的 JSON）。信任锚是 `crates/core/src/update/trust.rs` 里的
+  **编译期公钥数组**（keyring）；源里没有 `.sig`、钥不在表里、签名对不上，一律 `signature_*` 分类拒装，
+  **不可重试**。签名脚本 `packaging/sign_manifest.py`（零第三方依赖，`--self-test` 跑 RFC 8032 向量）。
+- **不得混淆**：项目自有签名解决的是「更新器怎么判断这份清单是不是我们发的」，**不解决 SmartScreen**
+  ——用户双击 exe 时看到的「未知发布者」要等 Authenticode 证书，那是另一条线。