补齐游戏分发校验重启恢复与失败可观测取证

- 新增 scripts/check-game-distribution-validation-restart-e2e.mjs：两段式 prepare/resume，在确认校验中途杀掉 api-server，覆盖暂存字节不丢、重新确认可恢复、待审积压可查、坏包 422 失败可诊断、公开版本不被误删
- package.json 注册 npm run check:game-distribution-validation-restart-e2e
- 里程碑阶段 D 第 3 条勾选，并补「本轮核对（阶段 D 重启恢复与失败可观测）」与阶段 D 现状描述
- pitfalls 记录两段式 E2E 的管理员凭据取决于 api-server 启动环境，以及同一状态文件只能 resume 一次

docs/project-memory/plans/【里程碑】游戏分发目录详情与在线游玩-2026-09-18.md

@@ -27,7 +27,7 @@
 - 阶段 A：真实 ZIP 上传、游戏身份、owner/幂等/CAS、状态机、DTO 与 schema 门禁已完成；真实 SpacetimeDB + 私有 OSS 的创建/上传/确认/重启恢复已有证据。**2026-09-28 更新**：阶段 A 的六条行为与验收已全部勾选（含跨账号越权、并发上传不混写、进程退出后按权威偏移续传、DTO/envelope 一致性），正式验收仍待 owner 评审。
 - 阶段 B：人工审核（后台列表、通过需 HTTPS 入口、拒绝需理由）、公开投影、发行网关（按公开版本服务、扩展名白名单、`nosniff`/CORP/CSP、带 Cookie 403）与作者下架已实现；**2026-09-28 更新**：审核治理（待审可见、可批可拒、结论可追溯、作者不能提交审核）、「更新待审/被拒不改变在线旧版」、`publicationRevision` CAS（过期审核、并发激活、过期下架、陈旧审核不复活已下架游戏）与作者/管理员下架后目录/详情/发行读取全部关闭都已在本地真实栈取证（见文末阶段 B 核对）；匿名直取发行包这一条已修：`platform-oss` 现在在内部 PUT / 分片追加 / 直传 policy 三处都下发对象级 ACL，严格模式下直传封面与发行包匿名直取都是 403（见 pitfalls 与 decision-log）；opaque sandbox 的真实浏览器行为也已用 Chromium 探针包取证（22 项 PASS）；每游戏独立来源已有可执行工件 `deploy/nginx/genarrative-release-origin.conf` 与门禁 `npm run check:release-origin-config`，并已在本机用真实 nginx + 真实网关验证按主机映射、Cookie 403 与平台命名空间 404；独立发行域名已由主规范 2026 决策用「平台同源路径 + sandbox 不透明来源」替代，不再是门禁；只剩「撤销传播符合最大缓存窗口」需要生产 CDN/TTL。
 - 阶段 C：AGC 客户端「发布到平台」面板与发布链路（dist 归一化根 `index.html`、摘要/字节数声明、幂等键、`localProjectId` 复用）已实现并有请求组装与 Rust 导出测试；网页 `/games/publish` 走同一服务端管道，本地已用真实文件选择验证；AGC GUI 自身的端到端发布仍待客户端环境验收。目录（关键词/分类/设备筛选、滚动与筛选恢复）、详情、游玩页（主动作后加载、超时重试、旋转提示、全屏、移动端门槛）与作者中心（状态、驳回理由、撤回、下架）已实现；本地已在桌面与 `390x844` 移动视口真实游玩。
-- 阶段 D：容量/额度、重启恢复、CDN 撤销与回滚演练尚未开始，依赖生产资源。
+- 阶段 D：**2026-09-28 更新**：200 MiB 上限档与发包边界、真实栈两段式重启恢复（含失败可观测与公开版本不被误删）已在本地真实栈取证；CDN 撤销窗口、发布/回滚演练、真实发行域名与生产账号验收仍依赖生产资源。
 
 细节与命令级证据见[实施计划【游戏分发阶段A领域合同】](【实施计划】游戏分发阶段A领域合同-2026-09-19.md)的「已完成证据」「运行时证据」「尚未完成」。
 
@@ -121,7 +121,7 @@
 
 - [ ] 真实环境中完整跑通“首次上传 → 校验 → 审核 → 公开 → 游客游玩 → 更新待审旧版在线 → 新版切换 → 下架撤销”。
 - [x] 200 MiB 包（现行上限，见 2026-09-23 决策记录）与获批文件数/展开量边界有可复核耗时、内存和失败证据；校验不会执行上传代码，服务资源有界（2026-09-28 在本地真实栈按新上限复跑，见文末阶段 D 核对）。
-- [ ] 校验执行器重启可恢复，审核积压与失败可观测，清理不删除仍被公开版本引用的文件。
+- [x] 校验执行器重启可恢复，审核积压与失败可观测，清理不删除仍被公开版本引用的文件（2026-09-28 在本地真实栈按两段式重启复跑，见文末阶段 D 核对）。
 - [ ] CDN purge 失败时仍在获批缓存 TTL 内拒绝新资源；明确已下载脚本无法远程抹除的边界。
 - [ ] 发布/回滚步骤保留当前公开版本，能关闭新提交和新版本激活；部署路由、缓存、响应头、日志脱敏和告警完成检查。
 - [ ] 主规范逐条证据矩阵齐全，未验证项明确列出；有任何核心路径未验证时不标记上线完成。
@@ -232,4 +232,16 @@
     - **展开量**：9 × 60 MiB = 540 MiB（每 6 字节塞 1 个随机字节，整包约 145 MiB、仍在 200 MiB 内）返回 422 / `ExpandedPackageTooLarge`。
     - **压缩比**：10 MiB 全零内容压成 10,556 字节（>100:1）返回 422 / `CompressionRatioTooHigh`。
     - **校验不执行上传代码**：校验实现 `module-game-distribution` 的 `package.rs` / `release.rs` 里检索 `Command::new` / `std::process::Command` / `spawn(` 无命中；包内 `index.html` 里那行会打接口的脚本在整个校验过程中没有被执行。
-  - 边界说明：失败用例都停在「上传校验」这一步（单发 PUT 会立刻回读校验），版本落到 `upload_failed` 且不会留下半包对象；成功档的 196 MiB 对象会留在 dev bucket 里，属于可丢弃的测试产物。
+  - 边界说明：失败用例都停在「上传校验」这一步（单发 PUT 会立刻回读校验），版本落到 `upload_failed` 且不会留下半包对象；成功档的 196 MiB 对象会留在 dev bucket 里，属于可丢弃的测试产物。
+
+## 本轮核对（2026-09-28，阶段 D 重启恢复与失败可观测）
+
+- 已勾选（阶段 D 第 3 条：校验执行器重启可恢复、审核积压与失败可观测、清理不删除仍被公开版本引用的文件）——本轮补齐
+  - 新增 `scripts/check-game-distribution-validation-restart-e2e.mjs`（`npm run check:game-distribution-validation-restart-e2e`，本地真实栈 + 真实 OSS，两段式 `E2E_STAGE=prepare|resume`，**11 项 PASS**）。跨进程状态写在 `E2E_STATE_FILE`，api-server 的重启由调用方在 prepare 与 resume 之间完成。
+  - **prepare**：管理员登录 → 注册作者 → 建游戏 → v1（1 MiB，包内标记 `V1-OK`）上传、送审、审核公开 → v2 整包 **205,521,777 字节（196 MiB）** PUT 成功 → 立刻发出确认（`POST …/package/complete`）并在同一步杀掉 api-server。确认请求以 `TypeError: fetch failed` 结束，说明进程退出时这次校验不会被写成 `uploaded` 静默成功。
+  - **重启**：`npm run dev:api-server`（SpacetimeDB 复用本地 `xushi-p4wfr`，未重启数据库）。
+  - **resume（可恢复）**：作者重登 200 → `upload-state.receivedBytes=205,521,777`，与杀进程前一致（暂存对象没因进程退出丢失）→ 用新幂等键重新确认得 200 且版本落 `uploaded` → 送审 202。
+  - **审核积压可观测**：`/admin/api/game-distribution/reviews` 的待审队列能查到该版本（本次 `pending=18`，队列里本就有其它积压）；`/admin/api/game-distribution/games` 能看到同一游戏的两个版本（`versions=2`）。
+  - **失败可观测**：再传一个结构损坏的包返回 **422 `PACKAGE_VALIDATION_FAILED` + `reason=InvalidArchive`**（作者当场可诊断）；同一版本回读落到 `upload_failed`；后台游戏列表出现 `statuses=upload_failed,pending_review,published`。失败原因同时落库：`spacetime sql --server http://127.0.0.1:3101 xushi-p4wfr "SELECT version_id, status, last_error_code FROM game_distribution_version WHERE status = 'upload_failed'"` 返回 `(some = "PACKAGE_VALIDATION_FAILED")`。
+  - **不误删公开版本**：v2 待审、v3 失败之后，`GET /api/game-distribution/releases/<gameId>/index.html` 仍 200 且正文仍含 `V1-OK`，公开版本内容没有被后续待审/失败版本清理掉。
+  - **明确缺口（未当成已验收）**：版本回读 DTO 目前只暴露 `status`，不暴露 `last_error_code` / `last_error_message`；作者或运维事后回看只能看到 `upload_failed`，具体原因只有失败当次的 422 envelope 与库内字段。把它做进回读 DTO 需要改 `GameDistributionVersionSnapshot` / `GameDistributionAdminVersionSnapshot` 的 ABI 并重发模块与绑定，本轮未做，列为后续事项。

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

@@ -6078,4 +6078,11 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 
 - **现象**：网页发布页飞快双击「提交审核」，服务端出现两份游戏（各带一个版本）。`isSubmitting` 是 React 状态，双击发生在同一次渲染窗口里时还没生效，再叠上 `prepareGamePackage` 的 ZIP 压缩耗时，两次点击各走一遍创建工作。
 - **处理**：`GamePublishPage` 加同步 `submitInFlightRef` 在途守卫（进入提交前同步置位、`finally` 复位），并让同一次发布（含失败后重试）复用同一组 Idempotency-Key（`publishKeyRef`，成功后清空），服务端按幂等重放；`check:game-distribution-web-publish-recovery-e2e` 断言「双击只落一份游戏与一个版本」，`GamePublishPage.test.tsx` 15 passed。
-- **教训**：任何「点一次会建资源」的入口都需要同步守卫或稳定幂等键，只靠 React 状态禁用按钮不够。
+- **教训**：任何「点一次会建资源」的入口都需要同步守卫或稳定幂等键，只靠 React 状态禁用按钮不够。
+
+## 2026-09-28 两段式重启 E2E 的管理员账号由 api-server 启动环境决定，重启后换凭据会让管理员断言全红
+
+- **现象**：`check:game-distribution-validation-restart-e2e` 的 prepare 段打印 `管理员登录成功 :: status=200`，杀掉 api-server 重启后，用同一组 `E2E_ADMIN_USER` / `E2E_ADMIN_PASSWORD` 跑 resume 变成 `status=401`，连带 `/admin/api/*` 的三条断言（待审队列、后台游戏列表、失败版本可见）一起 FAIL，看起来像重启把后台状态弄丢了；同一轮里作者登录、`upload-state`、重新确认、发行包读取全都正常。
+- **根因**：`.env.local` 里配置的是 `GENARRATIVE_ADMIN_USERNAME=admin` / `GENARRATIVE_ADMIN_PASSWORD=123456`，超管登录直接比对 `state.admin_runtime()`（即进程启动时的环境变量），不走库里的后台账号。上一次 api-server 若是被显式带上 `codex-admin / CodexLocal-4198!` 起起来的，重启回到 `.env.local` 后这组账号就会 401。
+- **做法**：两段式 E2E 的两次启动必须用同一组管理员凭据（本轮统一改成 `.env.local` 的 `admin / 123456`，实测 `admin` → 200、`codex-admin` → 401）；遇到 401 先用 `Invoke-WebRequest http://127.0.0.1:8082/admin/api/login` 探一次凭据，再判断是否是产品回归。
+- **附注**：同一个 `E2E_STATE_FILE` 只能 resume 一次。resume 段会额外建一个坏包版本，第二次跑「后台只看到两个版本」这类断言会因为多出 `upload_failed` 版本而失败；需要重跑就重新执行 prepare。同理，prepare 依赖 `game-distribution:publish` 灰度对该作者开启，脚本自己会先 PUT 特征开关。