docs(bugs): clarify recovered staging fetch stall

docs/research/pre_work_error_ledger.md

@@ -147,7 +147,7 @@ Prevention: store `STAGING_SSH_PRIVATE_KEY` only as one unwrapped base64 line; w
 
 ## ERR-095 | Gitea trusted-main fetch can stall until the whole deploy job times out | investigating 2026-08-06
 
-After exact-SHA staging gate `1473` succeeded, automatic deploy `1474` stopped making progress 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. The checkout had no command-level bound, so the 30-minute job timeout was the only escape and the shared mutation queue remained occupied.
+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.
 
 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.