fix(ci): 修复三处必致 CI 变红的工程缺陷

排查 Phase 23 收尾项「 GitHub Actions 从未跑绿」时，逐个在本地复刻 CI 的每个 job，
发现三个与业务代码无关、但足以让流水线恒红的缺陷。

1. 依赖锁文件被排除出版本控制（admin-web job 必红）
   .gitignore 原先同时忽略 pnpm-lock.yaml 与 package-lock.json，导致
   CI checkout 后 admin-web 根本拿不到 lockfile。pnpm install --frozen-lockfile
   在缺 lockfile 时不是降级重试、而是直接报错，因此该 job 必然失败；
   miniapp 的 npm install 也因失去锁文件而版本浮动。
   现在按包管理器逐一放行：admin-web 走 pnpm、miniapp 走 npm。
   admin-web/package-lock.json 仍保持忽略 —— 同一目录并存两把锁会让两种包管理器
   各按自己的锁安装，漂移时彼此看不出问题。

2. admin-web/pnpm-workspace.yaml 内容残缺（任何环境下都装不上依赖）
   该文件原先只有两行 allowBuilds（esbuild / vue-demi），既无 packages 声明也未写取值。
   pnpm 一旦检测到工作目录下存在 pnpm-workspace.yaml 就强制进入 workspace 模式，
   随后因读不到 packages 而报 packages field missing or empty。
   本仓库 admin-web 只有一个包，现显式声明单包 workspace，并补出 esbuild 与
   vue-demi 的 build 白名单 —— 二者 postinstall 是必需步骤：
   esbuild 下载平台原生二进制、vue-demi 生成 Vue 版本桥接。

3. CI 使用 runner 预装的 pnpm，版本会漂移
   pnpm 9 与 10 对「是否默认放行依赖 build 脚本」的语义相反，而上述
   allowBuilds / onlyBuiltDependencies 恰好是版本敏感配置项。 runner 镜像升级后
   会出现 install 能过、build 变红、且错误信息不指向真正原因的情况。
   现钉住 pnpm@9.15.9，使 CI 语义不再随 runner 变化。

本轮同时在本地复刻了 CI 的其余 job：
- migration job 的迁移序列校验：51 个迁移文件，版本 1 至 51 连续且唯一，通过。
- test-shell-guard：18 个 Python 文件未发现 skip / pass 空壳，通过。
- miniapp job 的 npm install 加 tsc --noEmit：通过。

.gitignore

@@ -10,6 +10,23 @@ package-lock.json
 yarn.lock
 pnpm-lock.yaml
 
+# 例外：依赖锁文件必须入库，CI 的可复现安装依赖它们。
+#
+# 2026-09-22 修复背景：上面四条规则此前把 admin-web/pnpm-lock.yaml 与
+# miniapp/package-lock.json 一并挡在版本控制之外，于是 CI checkout 后的环境
+# 与本机完全不同：
+#   - admin-web：`pnpm install --frozen-lockfile` 找不到 lockfile → 直接失败
+#     （frozen 模式的语义就是「必须存在且不可变更」，缺文件不是警告而是错误）；
+#   - miniapp：`npm install` 无 lockfile 约束，版本随上游浮动，
+#     `npx tsc --noEmit` 的结果不与任何一次本地验证对齐。
+# 二者共同导致「本地绿、CI 红」且二者都不可解释。
+#
+# 只放行每个包真正使用的那把锁：admin-web 走 pnpm，miniapp 走 npm。
+# admin-web/package-lock.json 仍然忽略 —— 同一目录并存两把锁会让两种包管理器
+# 各自按自己的锁安装，漂移时彼此看不出问题，属于典型的双锁冲突。
+!admin-web/pnpm-lock.yaml
+!miniapp/package-lock.json
+
 # Build outputs
 backend/target/
 admin-web/dist/