The code fix cannot reach connections already over the ceiling — the schedulers
filter them out before any job runs — so the mechanism change needs a data repair
alongside it. #742 did both; #757 shipped without one, which is why two rows are
still stranded two days later.
What actually stranded them (not job timeouts, which the branch first blamed):
until #757 a classified-transient failure on a final attempt still incremented
the counter, and both crossed the line in the hours before it deployed. Verified
against prod: 2 rows, 2 users, one of which has never completed a single sync
since 2026-06-07.
Matched exactly rather than with >=. handlePermanentError parks auth failures at
MAX_SCHEDULED_RETRIES + 1 deliberately, and there are 8 such rows in prod; a >=
filter would un-park them, 401 on the next cycle and send each user a second
"authentication failed" email. The counting path can only ever reach exactly
MAX_SCHEDULED_RETRIES, since that is where the scheduler stops dispatching.
`migrate --pretend` confirms the final scope, soft-delete scope included.
e60fdf4faa