Recover cleanup after run-history totals change #610

🤖 Generated by the Agentic Engineer

The native read-only cleanup caller in main CI 38784143518 failed at commit 24a32fa15c261a768a8ebbb97984692ec478498a because the run-history total changed between pages. Refusing an inconsistent inventory is correct. Requiring a separate workflow rerun to obtain a fresh read adds avoidable CI recovery work; GitHub currently refuses that job rerun while the rest of the workflow remains unfinished. This is distinct from #596's quota failures and #608's split-count check.

Add one bounded fresh run-history attempt for this specific consistency failure. Discard the entire partial inventory, preserve the original creation-time cutoff, join all reads before restarting, and share partition and rate-limit wait budgets across both attempts. Build a deletion plan only from a complete successful attempt. A second inconsistency, malformed/ambiguous data, authorization failure, cancellation or exhausted budget still fails before mutation; never replay a deletion or weaken the completeness checks.

Prove the production cleanup path with changing-history HTTP fixtures: initial partial data cannot enter the final plan; one consistent fresh inventory can complete; repeated drift and other failures remain bounded and produce no writes or completion receipt. Preserve existing stable, dense-history, retention, orphan, pagination, credential and retry controls. Keep the read-only hosted callers and aggregate required. Verify exact-head hosted CI, substantive review, protected merge and merged-source behavior before closure.

High priority because the observed failure is on main. Medium effort. No new credentials, workflow permissions, retry inputs or production service are needed.

Part of #287.