loop-escalation-sweep is the only flag-gated cron job in job-dispatch's switch without a config-as-code manifest-override re-check

[JSONbored]

Context

src/queue/job-dispatch.ts's processJob has seven flag-gated cron job types in its switch. Six of them — ops-alerts (lines 290-298), sweep-liveness-watchdog (299-309), reconcile-open-prs (316-324), reconcile-active-review-tracking (325-333), generate-maintainer-recap (221-228), rag-index-repo (349-360) — resolve a resolveXManifestOverride(env) and pass it into isXEnabled(env, override), a "defense-in-depth" pattern so a stale in-flight job that lands after a .loopover.yml-based flag flip still no-ops, not just an env-var flip.

loop-escalation-sweep (lines 310-315) only calls isLoopEscalationSweepEnabled(env) — env-var only. Confirmed via src/review/loop-escalation-wire.ts: it exports no resolveLoopEscalationManifestOverride at all. The capability was simply never built for this feature (added at #6349, after the config-as-code convergence pattern was already established for its siblings).

Net effect: an operator who disables Rent-a-Loop escalation via .loopover.yml (rather than the LOOPOVER_LOOP_ESCALATION env var) cannot stop an already-enqueued sweep job from running, unlike every comparable cron feature in this same switch.

⚠️ Required pattern — read any one sibling's manifest-override resolver (e.g. resolveOpsManifestOverride for ops-alerts) before starting. Add resolveLoopEscalationManifestOverride to src/review/loop-escalation-wire.ts mirroring that shape exactly, and wire it into isLoopEscalationSweepEnabled and the loop-escalation-sweep dispatch case the same way the six siblings already do — do not invent a different override mechanism.

Requirements

• Add resolveLoopEscalationManifestOverride to src/review/loop-escalation-wire.ts, mirroring an existing sibling resolver's shape (e.g. resolveOpsManifestOverride).
• Wire it into isLoopEscalationSweepEnabled(env, override) and the loop-escalation-sweep case in job-dispatch.ts's processJob, matching the six siblings' call pattern exactly.

Deliverables

• resolveLoopEscalationManifestOverride exists and is exported from loop-escalation-wire.ts.
• isLoopEscalationSweepEnabled accepts and honors the manifest override.
• job-dispatch.ts's loop-escalation-sweep case resolves and passes the override, matching its six siblings.

Test Coverage Requirements

src/** — 99%+ Codecov patch target, both branches. Mirror however one sibling job type's manifest-override is tested: a .loopover.yml-disabled repo's already-enqueued loop-escalation-sweep job no-ops even when the env var is still enabled.

Expected Outcome

An operator disabling loop-escalation via .loopover.yml reliably stops in-flight sweep jobs, the same defense-in-depth guarantee every other cron job type in this switch already provides.

Links & Resources

• src/queue/job-dispatch.ts (lines 290-360 for the six siblings' pattern, lines 310-315 for the gap to fix)
• src/review/loop-escalation-wire.ts (where the new resolver belongs)
• Wire a live, scheduled trigger for evaluateEscalation so an escalation reaches a human automatically #6349 (the issue that added loop-escalation-sweep without this capability)

[linear-code]

JSO-5548