fix(staging): retry exact gate checkout

docs/BUG_HISTORY.md

@@ -2240,3 +2240,19 @@
 - 相关记录：BUG-128、ERR-094、ERR-095
 - 复发自：BUG-129 第一轮修复未覆盖对象范围
 - 修复版本：`e59f15d352787f3d05425ba8c459d092e9801a20`；gate-attested controller bundle 已完成 staging exact-SHA 验收
+
+## BUG-130 | staging quality gate exact-SHA checkout 因过严低速阈值单次失败
+
+- 状态：investigating
+- 首次发现：2026-08-06
+- 最近更新：2026-08-06
+- 影响面：Gitea `Staging Backend Quality Gate` validate/publish 的 exact-SHA checkout；staging mutation controller、应用数据面与 production 未受影响。
+- 用户现象：docs-attestation staging gate run `1485` 在 validate 的首步失败；Gitea 已枚举/压缩 3,246/2,895 个 shallow objects，但客户端传输降速后触发 `curl 28 Operation too slow`、`early EOF`。publish 被依赖关系跳过，自动 deploy 未触发；公网继续健康运行 `e59f15d352787f3d05425ba8c459d092e9801a20`。
+- 触发条件：quality gate 的 exact-SHA `--depth=1` fetch 只有单次调用，并把低速失败设为连续 30 秒低于 1024 B/s；当前 Gitea 链路在约 20 KiB/s 波动后短时低于阈值。
+- 根因：`BUG-129` 消除了 mutation workflow 的 Git object fetch，但 quality gate 自身仍必须取得待测源码；其 checkout 没有 bounded retry，且低速阈值对当前受限链路过严。旧测试只断言 exact SHA/clean tree，没有覆盖 checkout retry 与低速边界。
+- 修复：validate/publish 两处 exact-SHA checkout 均改为最多 3 次、每次 hard timeout 300 秒；保留 connect timeout 15 秒，将低速失败收紧为连续 60 秒低于 1 B/s。每次仍只抓 `--depth=1 --no-tags origin "$GITEA_SHA"`，耗尽后明确 fail closed，不复用旧 artifact、不放宽 exact-SHA 或 clean-tree 校验。
+- 验证：待本地 workflow/YAML/run-script/pre-work 回归、完整 PR gate、staging push gate 和自动 deploy；完成前不得标记 resolved。
+- 防复发：质量门禁和 mutation controller 的网络边界分别测试；quality gate checkout 必须覆盖 attempt 数、hard timeout、低速阈值、exact-SHA refspec、最终错误和 clean-tree identity。
+- 相关记录：BUG-129、ERR-095、ERR-096
+- 复发自：无；属于同一 Gitea 链路在 quality-gate 阶段的独立缺口
+- 修复版本：待 bounded exact-SHA gate checkout 与 staging 验收