补齐跨渠道产物隔离核对并把 dev-mac 缺陷钉到字节级

- check:agc-update-channel-manifests：新增「不同渠道更新包不得字节相同」断言（需 AGC_UPDATE_VERIFY_DOWNLOAD=1），并核对 Windows 安装包文件名带本渠道产品名
- 只读核对 dev-win/dev-mac/release-win/release-mac：dev-win 0.1.154、release-win 0.1.150、release-mac 0.1.139 身份与版本一致；dev-mac 0.1.142 与 release-mac 0.1.139 的更新包 sha256 相同，字节级证明 dev 分区放了 release 渠道的产物
- 渠道安装身份隔离里程碑补本轮核对（发布产物身份 + 跨渠道唯一性），真机并存仍待验收
- macOS 里程碑与 pitfalls、decision-log 记录字节级取证与新断言

docs/project-memory/shared-memory/pitfalls.md

@@ -6103,6 +6103,6 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 
 - **现象**：线上 `https://agc-dev.oss-rg-china-mainland.aliyuncs.com/agc/dev-mac/latest.json`（`version=0.1.142`、`commit=c07c10c0c`）把更新包指向 `陶泥儿 Release.app.tar.gz`；下载解开看 `Contents/Info.plist`：`CFBundleShortVersionString=0.1.139`、`CFBundleIdentifier=world.genarrative.ai-game-creator.release`、`CFBundleName=陶泥儿 Release`。同一份清单的首装 DMG 却是 `陶泥儿开发版_0.1.142_aarch64.dmg`。也就是说签名是真的、对象也在，但**版本与渠道身份都是错的**。
 - **根因**：`build-macos-ci.mjs` 以前只 `rmSync` 「本轮要写的确切文件名」，构建目录里上一轮（或其它渠道身份）留下的 `*.app.tar.gz` 不会被清；而 `generateUpdateManifest()` 是**扫描构建目录、按优先级挑产物**（同名优先级再按字典序），于是挑走了残留的 release 身份包。mac 构建机是复用 workspace 的，这类残留会长期存在。
-- **判据**：只读核对要**打开产物看身份**，不能只看「地址存在 + 签名匹配」。`npm run check:agc-update-channel-manifests`（`AGC_UPDATE_VERIFY_DOWNLOAD=1`）现在会解出 mac 包的 `Info.plist`，断言「包内版本 == 清单版本」且「包内 identifier/产品名 == 本渠道身份」；本轮对线上取样得到两条 FAIL，正是这个缺陷。
+- **判据**：只读核对要**打开产物看身份**，不能只看「地址存在 + 签名匹配」。`npm run check:agc-update-channel-manifests`（`AGC_UPDATE_VERIFY_DOWNLOAD=1`）现在会解出 mac 包的 `Info.plist`，断言「包内版本 == 清单版本」且「包内 identifier/产品名 == 本渠道身份」，并额外断言**不同渠道的更新包不得字节相同**；本轮对线上取样得到三条 FAIL，正是这个缺陷。字节级佐证：`dev-mac/0.1.142/陶泥儿 Release.app.tar.gz` 与 `release-mac/0.1.139/陶泥儿 Release.app.tar.gz` 的 sha256 完全相同（`1dfc9deb79f7…`），说明 dev 分区里放的就是 release 那一次构建的产物。
 - **处理（2026-09-28 已修）**：构建前按后缀清空 `macos/` 下的 `*.app.tar.gz`、`*.app.tar.gz.sig`、`*.dmg`、`*.dmg.sha256`；构建后读 `.app/Contents/Info.plist` 断言版本/identifier/产品名；生成清单后再断言 `release.artifact` 就是本轮那一个。守卫在 `apps/ai-game-creator-shell/scripts/macos-release-identity.mjs`，回归用例直接用线上那份 0.1.139 release 身份包（`node --test` 59 passed）。
 - **教训**：凡是「按目录扫描挑产物」的发布步骤，都要么先清空同类产物、要么按本轮预期路径断言；只删「本轮要写的名字」等于把上一轮的坏包留在候选集里。现在共享入口 `generateUpdateManifest()` 也补了与平台无关的 `assertArtifactVersionMatches()`（文件名带 `_0.1.153_` 这类版本段时必须是本轮版本），所以即使将来某个流水线不再 `git clean -fdx`，旧安装包也会被拒绝而不是被发出去。还有一条更一般的：核对线上清单时，先看 decision-log 的现行口径（这里 macOS 已是 arm64 单架构），别拿过期里程碑文字当契约。