Reconcile any IntakeSource rows where status='active' but consecutive_failures >= settings.intake_max_consecutive_failures.

Background (2026-05-31): The intake worker auto-disables sources at the cf++ moment, so a poll at cf=9 incrementing to cf=10 flips status=error. Two paths can leave a row stuck at status=active, cf>=threshold:

(1) The /v1/intake/sources/{src_id}/activate endpoint pre-2026- 05-31 flipped status active without resetting cf — patched in the same PR as this endpoint. (2) A row was at high cf BEFORE PR #314 (intake auto-disable landed); the existing rows never had a cf++ event after the feature deployed because their poll_interval is 6h and the feature flag-check only runs at increment time.

Since the threshold check fires only on the next cf++ event, these rows soak poll cycles indefinitely (every poll_interval_minutes they spin up, fail, bump cf, log a WARNING, then sit again). This endpoint catches them up: any active row at cf>=threshold is flipped to status=error in one batched UPDATE.

Idempotent + cheap (one indexed scan + small UPDATE). Set ?dry_run=1 to inventory without writing.

Sensitive: requires the same admin token as the rest of /v1/admin/intake/*. No TG fan-out (the per-row WARNING was already logged at the cf++ event); the per-batch summary alone is enough for the operator dashboard.