Workspace cleanup pagination becomes stale after apply/removal

[chubes4]

During a real disk cleanup on 2026-06-25, workspace worktree reconcile-metadata --dry-run --limit=25 --offset=25 returned next_offset=50, but after applying metadata and removing newly eligible worktrees, the next dry-run at --offset=50 reported total=48 and inspected zero rows.

Observed flow:

• Ran bounded cleanup and removed eligible worktrees.
• Ran reconcile-metadata --dry-run --limit=25 --offset=25, which proposed 11 metadata writes and returned next_offset=50.
• Applied that page and removed newly eligible worktrees.
• Ran the suggested --offset=50; candidate set had shrunk to 48, so the command completed without inspecting remaining candidates.

Why this slows cleanup:

• Operators/agents have to infer that offsets are over a mutable candidate set.
• Following the advertised next command can skip remaining work after an apply/removal pass.
• Safe cleanup loops become manual and error-prone.

Desired shape:

• Provide a stable cursor/snapshot for plan/apply paging, or make apply/drain commands restart from the current first page until no safe progress remains.
• If offsets are intentionally mutable, print an explicit warning after apply that the next dry-run should restart at --offset=0 when rows were removed or metadata changed.

Evidence from this run:

• bounded-cleanup-eligible-apply removed 14 + 3 + 8 worktrees.
• reconcile-metadata --dry-run --offset=25 returned next_offset=50.
• reconcile-metadata --dry-run --offset=50 then reported total=48, scanned=0, complete=true.

AI assistance: filed from an OpenCode cleanup session using openai/gpt-5.5.