refactor(queue): split processors.ts into cohesive modules

[JSONbored]

Context

src/queue/processors.ts is 13,543 lines with 48 top-level exported functions spanning job dispatch, gate checks, AI-review orchestration, labeling, actuation locks, review-evasion enforcement, duplicate detection, signal-snapshot generation, and RAG wiring. Despite the size, an audit found this is unusually safe to split: only 2 of the 48 exports have any real external import anywhere in the codebase (processJob, imported by src/index.ts/src/server.ts; generateSignalSnapshots, imported by src/api/routes.ts) — everything else is exported without being consumed outside the file, meaning the blast radius of a mechanical split is almost entirely internal-consistency risk, not external-breakage risk. The file's 135 unexported top-level helpers are already clustered by concern internally (a large, coherent review-evasion block at ~11096-12205; a separate mention-command/throttling block; an official-contributor-detection block), so a split can largely follow lines the code has already drawn rather than inventing new boundaries.

This issue is explicitly sequenced LAST among the maintainer-only work from this audit — deprioritized relative to the FIFO/label/token-leak/observability fixes, since it's a pure maintainability improvement with no user-facing behavior change, and the highest-value fixes should land first without a large refactor in flight at the same time.

Requirements

1. Split into cohesive files, lowest-coupling first: actuation-locks.ts and signal-snapshot.ts are nearly self-contained and should go first to prove the pattern works; job-dispatch.ts, gate-checks.ts, and ai-review-orchestration.ts are the most interdependent and should go last.
2. One PR per new file — not one giant PR (this project's own PR-size convention favors ≤10 files, ~5 better; a single PR moving ~13,500 lines across 10 files would itself likely be flagged as oversized).
3. Pure, mechanical moves only — no behavior change, no "clean up while you're in there," in the same PR as a move. This matters doubly here since the codebase reviews itself one-shot: a move-plus-refactor is much harder to verify byte-for-byte than a pure move.
4. Use git mv-equivalent extraction so git log --follow/blame history is preserved per function.
5. Keep a temporary re-export shim in processors.ts for the 2 functions with real external callers (export { processJob } from "./job-dispatch", etc.) during the transition, so src/index.ts/src/server.ts/src/api/routes.ts don't need to change in the same PR as the code move.
6. Run the full local gate (npm run test:ci, unsharded npm run test:coverage, a TypeScript compile) on every extraction PR before pushing — a split that doesn't compile is caught for free, before the expensive gates run.
7. Verify locally whether the diff/coverage tooling correctly recognizes a git mv as a rename rather than scoring the moved file as entirely new code needing fresh Codecov patch coverage — if not, structure the extraction so it reads as a rename to the tooling.

Deliverables

A sequence of PRs (roughly, in order): actuation-locks.ts, signal-snapshot.ts, duplicate-detection.ts, slop-detection.ts, review-evasion.ts, ci-resolution.ts, retention.ts, gate-checks.ts, ai-review-orchestration.ts, and finally job-dispatch.ts + a slimmed (or removed) processors.ts.

Expected outcome

src/queue/processors.ts no longer exists as a single 13.5k-line file mixing unrelated concerns; each extracted file is independently reviewable and testable, with zero behavior change and zero external-caller breakage at any point in the sequence.

[linear-code]

JSO-3137