The down() migration uses plain `DROP INDEX IF EXISTS` rather than `DROP INDEX CONCURRENTLY IF EXISTS`, which acquires an AccessExclusiveLock that blocks all reads and writes on the `identity_access_tokens` table for the full duration of the drop. On the 64M-row throttled-EBS table this PR explicitly calls out, rolling back this migration in production would cause a write outage on identity access token operations; change line 36 to `DROP INDEX CONCURRENTLY IF EXISTS idx_identity_access_tokens_i

The do-while loop in `removeIdleTokens` can spin infinitely if any batch succeeds before a permanent DB failure. Once a batch returns N deleted IDs, `deletedTokenIds` remains non-empty forever because the `catch` block never resets it — so even after MAX_RETRY_ON_FAILURE consecutive failures the left-hand condition `deletedTokenIds.length > 0` keeps the loop alive, bypassing the retry guard entirely and hammering the broken database every 500 ms. Fix: add `deletedTokenIds = []` at the top of the