## Problem The live-purge and file-purge stages carry a per-chain resume point, and the constant that holds it explains why: refusals collect at the front of an id-ordered batch, and a cap's worth of them fills every batch forever. Two other stages have the same shape and had no resume point. **The archive stage.** Its permanent refusals are a segment whose `to_created` is unstamped, a range holding an erasure nothing accounts for, a destination file a crashed run left in place, and a lifecycle signature that does not validate. Each survives every retry until an operator attends to it. It is one stage worse than a purge stall, because live-purge only takes segments that have been archived, so retention stops for the whole chain rather than for one stage of it. **The transient-purge stage.** `purgeSegmentTransientContext()` reads the segment through `Segment\SegmentReader::loadSegmentRowForTransition()`, which refuses one whose lifecycle signature does not validate, so it has the same permanent refusals. Its cap is `MAX_TRANSIENT_PURGE_PER_CRON_RUN` = 500 rather than 50, so it takes ten times the damage to fill a batch, and what filling one costs is worse: transient-purge is the erasure stage, so the context an operator asked to be kept only for a while is kept indefinitely while the settings still say the schedule is configured. ## Fix `STATE_ARCHIVE_CURSOR` and `STATE_TRANSIENT_PURGE_CURSOR` give both stages the cursor the two purge stages already share, through the same `readStageCursor()` / `advanceStageCursor()` pair and the same rule: a full batch advances the resume point to its last id, a short one wraps it back to zero, so nothing is skipped permanently. In the archive stage a segment held back for its transient-purge counts as examined, because as far as the resume point is concerned that is what a refusal is. Both prefixes are registered in `getStateKeyPrefixes()`, so an uninstall sweeps them. `UninstallStateTest::testEveryPerChainStatePrefixIsListedForUninstall()` scans live constants and requires an exact match, so forgetting one fails there. ## Stages deliberately left alone `runCoverage()` reads rows rather than segments and has to start from the oldest uncovered one, because segments must bracket contiguous ranges. A resume point there could leave a permanent gap in coverage rather than fix a stall, which is a worse failure than the one it would solve. `runCompaction()` is an unconditional pass with no capped batch to resume. ## Test coverage Both confirmed failing against the unfixed code: - `testArchiveRefusalsDoNotBlockTheRestOfTheChain`: `MAX_ARCHIVES_PER_CRON_RUN` + 1 bare segments carrying a lifecycle signature that does not validate, then a healthy one behind them. Without a resume point the healthy one is never archived, however many ticks run. - `testTransientPurgeRefusalsDoNotBlockTheRestOfTheChain`: the same fixture at the larger cap, asserting the healthy segment's transient context is purged. Two existing tests hold the edges: `testChainsWithNothingStuckWriteNoResumePoints` (a healthy chain writes no cursor at all, so this costs no state write per stage per chain per tick) and `testEveryPerChainStatePrefixIsListedForUninstall`. The cap's docblock explained itself by naming a `max_archived_to_id` watermark that had been removed. It says what the cursor is for instead. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the fix and its tests. I reviewed both, and each test was confirmed to fail against the unfixed code and to pass with the change.)