Long-running exact-base review workflows can starve publication when the base branch is…

Long-running exact-base review workflows can starve publication when the base branch is merging faster than the review completes. Revalidate the base immediately before launch and immediately before push; after repeated staleness, stop instead of accumulating merge commits or publishing a verdict for an obsolete base. The practical recovery is a quiet integration window or a faster bounded review path that preserves the same proof obligations. This applies when policy requires the reviewed base SHA to equal the live target; it does not mean every unrelated base commit invalidates ordinary local tests when exact-base freshness is not a merge gate.

Evidence/example — 2026-09-09: A staging PR was merged locally and received two clean native reviews, but unrelated staging PRs landed during each 10–15 minute review. A third attempt detected another base advance before launch and returned REVIEW_STALE. Following the repeated-staleness guard prevented pushing a branch that still conflicted with the newest target or claiming a stale review as current. Source provenance: local Git SHAs and GitHub PR/base metadata for e3-solutions/theft PR #813; Linear COR-4098 records the checkpoints.