Constant MAX_CHECKPOINT_RESUMES 

pub const MAX_CHECKPOINT_RESUMES: u32 = 3;

Ceiling for crate::state::State::checkpoint_resumes before a checkpoint auto-decide relaunch (D-03/D-04, 28-03) stops resuming and falls through to the never-silent gate instead, its context naming the exhaustion. Bounds consecutive claude --resume relaunches for one stage’s agent run against a checkpoint that keeps re-firing.

Takes the tighter MAX_CONSECUTIVE_FAILURES-style ceiling rather than the more lenient MAX_INFRA_FAILURES: a re-firing checkpoint is a decision the agent is failing to close on its own, not a transient infrastructure blip, so it does not deserve the same tolerance an OOM blip or a missing binary gets. An unbounded resume loop here would be structurally the same “gates hang forever” failure class D-09 (28-CONTEXT.md) documents — this ceiling is what keeps it from becoming that.

Any increment of checkpoint_resumes must use saturating_add, exactly like crate::state::State::infra_failures and crate::state::State::preflight_retries, so a stuck loop cannot overflow u32. Reset to 0 by every ORDINARY fresh stage launch (pipeline_launch::launch_stage_inner) — never by transition() — so the ceiling bounds one stage’s resume budget, not a phase’s entire lifetime, the same distinction MAX_INFRA_FAILURES’s doc comment draws for infra_failures. On exhaustion: fall through to the never-silent gate with a reason naming the exhaustion — never a silent stop, never an unbounded loop.