fix(staging): deploy gate-attested controllers

docs/BUG_HISTORY.md

@@ -2227,16 +2227,16 @@
 
 ## BUG-129 | staging trusted-main checkout 无界 fetch 导致自动部署长期占用 mutation queue
 
-- 状态：resolved
+- 状态：investigating
 - 首次发现：2026-08-06
 - 最近更新：2026-08-06
 - 影响面：Gitea staging deploy/migration 控制器的 trusted-main checkout；production 与 staging 应用数据面未受影响。
-- 用户现象：exact-SHA quality gate run `1473` 成功后，自动 deploy run `1474` 在 `git fetch --no-tags origin main "$DEPLOY_SHA"` 长时间没有日志进展；期间 staging 公网与 `.state/deployed-revision` 均保持上一健康 SHA，SSH/远端 mutation 尚未开始。fetch 后续自行恢复，run 最终于 18 分钟完成并成功部署 `02cc483b7c303e6cc0f26fb31462c50adb007f12`，5 个容器 restart count 均为 0。
-- 触发条件：Gitea runner 在空仓库中抓取 reviewed `main` 和目标 SHA 时传输长时间停滞；底层远端/网络原因未闭环。checkout step 没有命令级 timeout/retry，只依赖 30 分钟 job 总超时。
-- 根因：已确认的控制面根因是发布控制器对镜像拉取有 bounded retry，却对 trusted-main Git fetch 采用无界单次调用；无论底层传输为何停滞，该调用都会长期占用 `staging-mutation` queue，并推迟后续受控重试。底层 Git 传输停滞原因保持 blocked，不作推断。
-- 修复：Gitea deploy 与 migration 的 trusted-main fetch 改为最多 3 次、每次 120 秒的 bounded retry，重试间隔递增；耗尽后明确 fail closed。仍只 checkout `origin/main`，仍要求目标 SHA 是 reviewed main ancestor，不改变 exact-SHA artifact、forward-only 或 manual rollback 边界。
-- 验证：原 run `1474` 最终成功部署 `02cc483b7c303e6cc0f26fb31462c50adb007f12`，公网 health、主机 state 与 `main/staging` 精确一致，5 个容器 restart count 均为 0；本地 staging workflow contracts 31/31、修改后 YAML 解析、mandatory pre-work 和 diff 检查通过；Gitea PR quality gate run `1475` 成功。修复后 exact-SHA staging 控制面部署仍按正常发布流程单独核对，不将原 run 的自行恢复冒充为 bounded retry 已在真实故障中触发。
-- 防复发：所有 release-controller 网络调用必须同时具备命令级上限和失败闭合；不得仅依赖 job 总 timeout。回归测试必须同时覆盖 deploy 和 migration 的 attempt 数、单次 timeout、最终错误和 ancestry check。
+- 用户现象：exact-SHA quality gate run `1473` 成功后，自动 deploy run `1474` 在 `git fetch --no-tags origin main "$DEPLOY_SHA"` 长时间没有日志进展；fetch 后续自行恢复，run 最终于 18 分钟成功部署 `02cc483b7c303e6cc0f26fb31462c50adb007f12`。第一轮 bounded-retry 修复合入后，run `1480` 的 3 次 120 秒 fetch 全部在服务端压缩 16,093 个对象时耗尽并 fail closed；SSH/远端 mutation 未开始，公网/state 继续健康运行 `02cc483b7c303e6cc0f26fb31462c50adb007f12`。
+- 触发条件：空仓库命令 `git fetch --no-tags origin main "$DEPLOY_SHA"` 同时请求分支和目标 SHA，导致 Gitea 为每次尝试枚举/压缩完整历史对象；runner 与服务端之间的传输无法在 120 秒内完成。
+- 根因：原控制器既没有命令级 timeout，也错误地为正常前向发布抓取 full-history dual ref。第一轮修复只增加 bounded retry，解决了无界占用，但旧回归测试只断言 timeout/attempt/ancestry，未限制传输对象范围，因而未拦住连续三次重新打包完整历史。
+- 修复：不再让 mutation runner 做任何 Git object fetch。成功 staging gate 从其已验证的 exact SHA 生成仅含 tracked `deploy/` 与严格 manifest validator 的 `controller.tar`，将 tar SHA-256 写入四字段 manifest，并与 immutable image digests 一起上传。deploy/migration 从 exact successful gate artifact 下载 bundle，强制校验 controller SHA、tar hash、路径、重复项、类型和 2 MiB 上限后才解包；正常发布使用当前 `main == staging` controller，手工旧版 rollback 也不得执行旧 controller。refs 与 forward/rollback 关系通过有界 Gitea API 和完整 commit-DAG 路径证明，字段缺失、分页不完整、头不一致或证据冲突均 fail closed。
+- 验证：第一轮 bounded retry 的本地 workflow contracts 31/31、PR gates `1475/1477` 与 staging gate `1479` 成功；run `1480` 证明 3 次 120 秒耗尽后无半部署。bundle 修复本地 manifest/workflow contracts 34/34、三份 YAML、shell、真实 25-entry/122,880-byte controller tar hash/安全检查、mutation Git-object-op=0、mandatory pre-work 和 diff 检查通过。完整 PR gate、staging gate 和 exact-SHA deploy 待完成；完成前不得再次标记 resolved。
+- 防复发：所有 release-controller 网络调用必须有命令级上限和失败闭合；mutation workflow 禁止 `git fetch/ls-remote/cat-file/merge-base/checkout/init`。控制器必须来自 exact successful gate 的 hash-bound artifact，正常与 rollback 均使用当前 reviewed controller；测试必须覆盖 artifact identity、tar safety、commit-DAG proof 和旧 Git object 路径为零。
 - 相关记录：BUG-128、ERR-094、ERR-095
-- 复发自：无
-- 修复版本：`52b467cbe56f820a6acc19bb3fe3ebbf4ad55776`；待合并后由 staging exact-SHA 发布采用
+- 复发自：BUG-129 第一轮修复未覆盖对象范围
+- 修复版本：待 gate-attested controller bundle 与 staging 验收

docs/research/pre_work_error_ledger.md

@@ -145,11 +145,11 @@ A failed exact-SHA staging deploy displayed the multiline staging SSH private ke
 
 Prevention: store `STAGING_SSH_PRIVATE_KEY` only as one unwrapped base64 line; workflows decode it into a mode-`0600` temporary key, validate it with `ssh-keygen`, and delete the temporary directory on every exit. Contract tests must reject direct multiline `SSH_PRIVATE_KEY` injection or `printf` of a decoded secret variable. A leaked staging key must be rotated and revoked before any rerun; production keys remain a separate boundary and were not involved in this incident.
 
-## ERR-095 | Gitea trusted-main fetch can stall until the whole deploy job times out | mitigated 2026-08-06
+## ERR-095 | Gitea trusted-main full-history fetch stalls or exhausts every bounded attempt | investigating 2026-08-06
 
-After exact-SHA staging gate `1473` succeeded, automatic deploy `1474` stopped making log progress for an extended period in the empty-repository `git fetch --no-tags origin main "$DEPLOY_SHA"` step before any SSH or staging mutation. Public and state SHAs remained on the previous healthy release during the stall. The fetch later recovered and the 18-minute run successfully deployed the exact SHA, but the checkout had no command-level bound; without recovery, the 30-minute job timeout was the only escape and the shared mutation queue would remain occupied. The underlying Git transport stall is not proven.
+After exact-SHA staging gate `1473` succeeded, automatic deploy `1474` stopped making log progress for an extended period in the empty-repository `git fetch --no-tags origin main "$DEPLOY_SHA"` step before any SSH or staging mutation. The fetch later recovered and the 18-minute run successfully deployed the exact SHA. The first mitigation added three 120-second attempts, but run `1480` proved every attempt still asked Gitea to enumerate/compress 16,093 full-history objects and then timed out. It failed closed before SSH; public and state SHAs remained on the prior healthy release. The first fix bounded queue occupation but did not reduce the transfer, and its regression test did not reject the full-history dual-ref form.
 
-Prevention: wrap the Gitea deploy and migration trusted-main fetch in three 120-second bounded attempts with incremental delay and explicit fail-closed exhaustion. Preserve the reviewed-main ancestry check, exact-SHA gate artifact, forward-only deploy policy, and shared mutation queue. Never treat an in-progress or timed-out fetch as a deployment result.
+Prevention: Gitea mutation workflows must perform no Git object operations. A successful staging gate packages its already-verified exact-SHA `deploy/` controller plus manifest validator into `controller.tar`, binds its SHA-256 into the strict image manifest, and uploads both as one immutable artifact. Deploy/migration must verify artifact run/SHA, controller digest, archive paths/types/duplicates/size, current `main == staging` refs, and a complete Gitea compare commit-DAG path before mutation; any missing or inconsistent evidence fails closed. Manual rollback still uses the current reviewed controller, never the old target's controller. Preserve exact-SHA images, forward-only defaults, shared mutation lock, and bounded API/artifact requests.
 
 ## Fragment Sweep Command Set