补齐游戏分发发布回滚窗口与发行网关缓存取证

- 新增 scripts/check-game-distribution-ops-rollback-e2e.mjs：关闭/开放发布开关、关投稿保在线、管理员批准被拦、拒绝审核与安全下架仍可用、换版保留旧版本、发行网关响应头与 60 秒缓存窗口、日志脱敏、边缘 /games/<gameId>/ 路由映射（40 项 PASS）
- package.json 注册 npm run check:game-distribution-ops-rollback-e2e
- 里程碑阶段 D 第 4、5 条勾选并补「本轮核对（阶段 D 发布回滚窗口与发行网关缓存）」，含变异验证结果
- pitfalls 记录发布开关用例要连拒绝审核与安全下架一起验，以及本机 check:production-health-patrol 必然 FAILED

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

@@ -6086,3 +6086,15 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 - **根因**：`.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 特征开关。
+
+## 2026-09-28 发布开关回滚窗口要连管理员拒绝/安全下架一起验，否则会把“关投稿”做成“关后台”
+
+- **现象**：只按“关闭 `game-distribution:publish` 后写入口 503”写用例，会漏掉两个方向的问题——① 关闭窗口里管理员**批准**新版本也必须被拦住，否则回滚窗口形同虚设；② 拒绝审核与管理员安全下架 / 恢复在关闭窗口里必须仍然可用，否则运营在最需要救火时会发现自己也进不去。
+- **做法**：`scripts/check-game-distribution-ops-rollback-e2e.mjs` 把这两类方向写进同一条用例：7 条写入（含管理员批准）断言 `503 GAME_DISTRIBUTION_PUBLISH_DISABLED`，同时断言目录/详情/`/my-games`/审核队列/发行入口 200 且 `publicationRevision` 不变，并在关闭窗口内实测拒绝审核与管理员下架 → 恢复。改 `ensure_publish_enabled` 的调用位置（例如给下架也加上开关检查）会立刻打红。
+- **变异验证**：把 `ensure_publish_enabled` 临时改成直接 `Ok(())`，脚本 14 项转红；这类“开关语义”用例必须做一次变异验证，否则无法区分“开关生效”与“断言恒真”。
+
+## 2026-09-28 `check:production-health-patrol` 在 Windows 本机必然 FAILED，别当成回归
+
+- **现象**：本机跑 `npm run check:production-health-patrol` 输出 `[check:production-health-patrol] FAILED`，理由是「nginx gateway mode 巡检应成功。预期退出码 0，实际 2」，巡检 JSON 里 6 条 `service:*` 全是 `服务状态异常: spawn systemctl ENOENT`。同一轮的 `api:/healthz`、`bgfilter:/readyz`、`spacetimedb:/v1/ping`、`public:/` 都是 200。
+- **根因**：这个 harness 用桩 `systemctl` 驱动巡检脚本，Windows 上 `spawn systemctl` 直接 `ENOENT`，服务态检查不可能通过；它验证的是 Linux + systemd 的生产形态。
+- **做法**：本机只跑 `npm run check:production-health-patrol-env`（本轮 OK）确认巡检变量口径；`check:production-health-patrol` 留给服务器/CI 复核，别据此判定巡检脚本本身坏了。