fix(queue): eliminate duplicate scheduled work and gate jitter

[JSONbored]

Parent: #1936

Problem

Hourly or bursty queue spikes suggest scheduled work and webhook-triggered work can still overlap. Beta-stable needs strict no-waste scheduler behavior: no polling loops, no duplicate sweeps, and no review job starting before required CI state is meaningful.

Requirements

• Scheduled regate/backfill work should not fan out while equivalent work is already pending or processing.
• Webhook bursts should coalesce where behavior is safe.
• Orb review/gate jobs should not repeatedly appear transiently running after already publishing a final state.
• Closed, stale, or head-changed PRs must not receive visible output from old work.

Deliverables

• Audit scheduled jobs for hourly fanout patterns and overlapping triggers.
• Add explicit queue introspection/backpressure for remaining scheduled job types, not just regate sweeps.
• Add idempotency keys or terminal-state guards for public review/check publication where needed.
• Add tests for duplicate scheduled sweeps, closed PRs, head changes, and CI-not-ready transitions.

Acceptance criteria

• Hourly scheduled events do not create avoidable queue spikes under normal load.
• A job already known to be stale exits before expensive GitHub reads.
• The Orb review check/comment does not flip back into running after reaching a terminal state unless there is a new head/event that legitimately requires it.
• The queue can continue draining useful work even when some jobs are deferred by GitHub budget.

Expected outcome

The queue stays smooth under bursty GitHub activity and avoids creating work that cannot produce a valid review outcome.

[linear-code]

JSO-2027

[JSONbored]

Analysis input — temporal smoothing is a distinct gap from dedup

This issue targets duplicate scheduled work and terminal-state/gate jitter — both real. Two adjacent findings from the rate-limit audit that are worth scoping here or in a sibling:

1. The hourly burst is a temporal problem, not (only) a duplication one. Even with perfect dedup, enqueueScheduledJobs (src/index.ts:91-190) enqueues ~10 job types — several of them per-repo fan-outs — at the same minute === 0 instant. The per-repo fan-outs stagger internally, but:

• All fan-outs start at delay 0 on the same tick, with overlapping delay windows and no cross-fan-out phase offset (src/queue/processors.ts: signal index*10 cap 600, regate index*10 cap 600, rag index*30 cap 900, backfill index*45|15 cap 900). Repo[0] of every type + all singleton jobs coincide, and one repo is hit by multiple fan-outs at once.
• The Math.min(index*step, cap) clamp collapses the tail into a thundering herd: every repo past cap/step fires at the same max-delay instant.
• Only agent-regate-sweep + backfill-registered-repos yield to MAINTENANCE_RESERVED_HEADROOM; the other 8 hourly jobs enqueue regardless of budget.

Fix direction: assign each scheduled job/repo a deterministic phase slot across the hour (hash → one of the 30 2-min slots), gate all fan-outs behind the maintenance headroom, and replace the min(cap) clamp with round-robin slot assignment so the tail keeps spreading. (Filing this as a dedicated perf sub-issue since it's smoothing, not dedup — cross-linking here.)

2. Coalescing/idempotency coverage gap. fanOutAgentRegateSweepJobs has atomic fan-out dedup (claimRegateFanoutSlot) + an in-flight draining guard (src/queue/processors.ts:960-1026), and #1876/#1934 added maintenance-job coalescing. But generate-signal-snapshots, rag-index-repo, build-*, and the refresh-* singletons have no equivalent enqueue-time "is an equivalent job already pending/processing?" guard — a cron catch-up after a restart (or fan-out jobs delayed behind a backlog then drained together) can double-enqueue them. Extending the claimRegateFanoutSlot pattern (or a generic per-(type,window) dedup key) to every scheduled fan-out closes this.