Reclaim the settled cleanup receipts nothing cites any more

[ppXD]

Summary

• One new cursor on the durable-retention plane, registered together with its class (a class exists only with a cursor): Cursors/CleanupReceiptRetentionCursor, 30 d. A receipt is a ledger row whose whole content is a statement about something that is over, so reclaiming it means DELETING it — there is nothing to purge first, and nothing a tombstone could say that a missing settled receipt does not.
• Reclaimable outcomes are exactly the two RunCleanupReceipt.IsSettled already names: Completed and Compensated, held against that definition by a test rather than against a second opinion about it. Orphaned is addressed to a sweep on the host that owes the teardown and can still become Compensated. Unknown is neither settled nor beyond reach: the ledger's upsert (IRunCleanupLedger.cs:51-55) fences only the two settled outcomes, so a live orphan a host cannot even attempt to tear down moves Orphaned → Unknown and leaves 0229's orphan queue for good — and the Room COUNTS those rows (RoomProjector.SummarizeRecovery), over every receipt of a run and with no age bound, to say how many resources are in an unknown cleanup state.
• Citer: paired_qualification_result_pin.pinned_id — the pin table from Reclaim log-stream bytes nothing cites any more #1993. Pinned by a list, cross-checked against the EF model (a future column naming a receipt reds), against ClassifyAsync's own probe body (a listed site with no probe reds), and against the claim's raw SQL (the IN list and the pin kind are one rule written twice, and two copies drift unobserved).
• Migration 0237: one nullable retain_until on agent_run_cleanup_receipt, plus a partial index matching the claim's DISTINCT ON (team_id) … ORDER BY team_id, recorded_at, id shape. The index is built in-script rather than CONCURRENTLY because DbUp runs each script in one transaction; the SHARE-lock window is stated in the migration, and the table holds a handful of rows per abandoned run.
• Two repairs to the shared loop. The batch budget is per cursor, not spent in class order — one plane's backlog could otherwise starve every plane behind it for ever while the sweep reported a healthy count. And SettleAsync now receives the same window the claim used, so a deleting statement repeats the time predicates that admitted the row.

Not built, with the evidence

• Capture gaps — workflow_run_capture_gap_guard() (0146:253-255) refuses DELETE because "a removable gap makes a complete manifest reachable by deleting the evidence"; a gap can only honestly go with the manifest whose verdict it qualifies.
• Paired-qualification results — paired_qualification_result_immutable (0219:42-44) refuses UPDATE and DELETE, and a result's citers are not enumerable in columns at all: QualificationReceipt carries no column naming a result and records its cohort and metrics as JSON, which is the shape this plane's charter excludes.
• Budget reservations — the Room's run-scoped readers are UNWINDOWED: RoomProjector.BudgetAsync and TerminalEvidenceAsync select every reservation of a run with no time predicate and derive CommittedUsd, CapUsd, UnbudgetedUsd and UnresolvedClaims from them, which RoomNarrative renders as "$X committed". Reclaiming the oldest rows of a long run would leave that figure quietly wrong rather than absent. It needs a durable per-run summary to outlive the rows first — a money-plane change, not a retention slice. (The 90 d floor would have been three times the only cap window, TeamCostCap.RollingThirtyDaysSpan; that arithmetic was never the problem.)
• artifact_transfer_intent still needs artifact_cas_transfer_guard() relaxed.

The policy table states all four refusals where a reader will look.

Test plan

• Unit: full suite 10897 passed / 1 skipped / 0 failed.
• Integration (real Postgres): 501 passed / 1 skipped / 0 failed across Retention|Budget|Room|Recovery|AgentRunLog in one invocation; 13 of them new. Own-row assertions throughout — no sweep tallies — and the class deletes what it staged in teardown.
• Mutations run, each named test red then green again: Unknown back in the reclaimable set (both by claim and through the Room's own fold); the pin probe dropped; Orphaned admitted; the delete's repeated time predicates dropped; only Quarantine and Collect settled; the SQL and the allow-list drifted apart; one batch budget shared across cursors.

Deploy notes

• Rolling-safe. retain_until is a nullable ADD COLUMN with no default — metadata-only, no rewrite — and NULL is what an older binary writes and reads. agent_run_cleanup_receipt carries no trigger, so no guard had to learn about it.
• Nothing is reclaimed for at least 30 days plus a further day of quarantine after this ships, so the first sweep that can delete anything is well past a rollback window.
• The cursor rides the existing hourly ReapExpiredDurableRecordsCommand; there is no new job and no new schedule.