Reconnecting is the documented way out of a connection the schedulers have
stopped dispatching, and it was the only one of the four "try again" paths that
didn't clear `consecutive_sync_failures`. Compare ConnectionController::sync,
ConnectionController::update, AccountMappingController and the job's own success
path — all reset to 0.
So a user who reconnected a connection parked at MAX_SCHEDULED_RETRIES + 1 came
back Active still carrying the count that parked it, and the first failure
afterwards re-parked it immediately — none of the three attempts the ceiling is
supposed to grant, right after paying the SCA redirect to escape exactly that
state. It is also the one route by which a single out-of-band job death could
reach the ceiling, which is what the previous commit closes from the other side.
Both reviews found this independently while checking that commit's premise.
030de06618