Purge expired refresh_tokens (retention sweep; sibling of #259) #270

Deployment-readiness gap (#244), RECOMMENDED — flagged by 2 of 3 reviewers.

Problem

The refresh_tokens table grows without bound. Every login/refresh inserts a row, and rotation continuously inserts new ones; expiry is checked at use (IdentityProvider.cs) but nothing ever deletes expired/revoked rows — the only recurring sweep is DailyEntryLockSweep. Over months this is unbounded table + index bloat (a capacity concern feeding #243) and indefinite retention of session lineage.

The sibling idempotency_records unbounded-growth problem is already tracked in #259 — this issue is scoped to refresh_tokens only. The two purges can share one durable-worker sweep.

Fix

Add a periodic cleanup (another DurableJobWorker sweep) that deletes refresh tokens past ExpiresAt + a grace window, retaining lineage only as long as reuse-detection requires. Add a covering index for the delete predicate. Monitor row/index growth.

Verify

After a synthetic login/refresh load, confirm the sweep collects aged rows and table size stabilizes; confirm active tokens and in-window reuse-detection are untouched.

Part of the #244 deployment-readiness audit; tracked in epic #15. Related: #259.