queue: make jobClaimSortKey's oldest-first ordering actually work (Phase 1 of #9499) — one omission fixed, a CI guard for the rest

[JSONbored]

Parent: #9499

Summary

Phase 1 of #9499: make the existing oldest-first ordering mechanism actually work, before deciding whether an explicit focus gate (Phase 2) is still needed on top of it.

jobClaimSortKey sorts agent-regate-pr jobs by the PR's own createdAt ascending — genuine oldest-first, and JobMessage.prCreatedAt's own doc says it exists for exactly this. But an omitted prCreatedAt does not merely lose the ordering: jobClaimSortKey falls back to LEGACY_AGENT_REGATE_SORT_BASE_MS + prNumber (≈9.5e11), which sorts ahead of every real 2026 PR (≈1.78e12) — an omission actively inverts the ordering for that producer's jobs.

Five of eight producers had drifted this way.

What was verified, and one correction to the parent issue

Two of the parent's five flagged sites (processors.ts:5032 and :5086) already carry prCreatedAt on current main — confirmed by direct inspection, not by re-reading the issue. Only scheduleTrailingMergeableStateReReview (processors.ts:5080, the trailing mergeable-state re-check) was genuinely missing it.

Also corrected: the parent's side-note that mergeTrainMode might be dead code on HEAD is wrong. Verified end to end (parseFocusManifestContent → resolveEffectiveSettings): a repo .loopover.yml settings.mergeTrainMode: enforce resolves to enforce. The "off" at repositories.ts:914 is only the DB-layer default, same as its sibling config-as-code settings — the parser lives in packages/loopover-engine/src/focus-manifest.ts:3160, outside the src/-scoped grep that produced the doubt. Recorded on the parent issue too, so it is not re-investigated.

Deliverables

• Thread prCreatedAt through scheduleTrailingMergeableStateReReview — the one genuine omission.
• Add scripts/check-regate-sort-key.ts: every type: "agent-regate-pr" producer must carry prCreatedAt within its own object literal, or be explicitly allowlisted with a reason. A type-level guard cannot express this (prCreatedAt is legitimately optional on JobMessage), so this reads producer sites directly — the same "state the exception, don't infer it from absence" shape as check-dead-source-files.ts's entry points.
• Wire it into test:ci and CI, alongside the sibling drift checks.

Explicitly out of scope for this sub-issue

• The coalesce key on maybeEnqueueSiblingRegateForMergedPr and the isRegateRepairExhausted repo#pr#headSha rekey — both already landed independently (drift: the #9399 sibling-guard pattern is live in four more places — fix the four, then remove the structure that generates them #9491's sibling-drift work and the queue: no 'current focus' concept exists, and oldest-first ordering is defeated by 5 of 8 regate producers omitting prCreatedAt #9499-adjacent repair-budget fix), verified present on current main.
• Phase 2 (an explicit focus gate) — the parent issue's own stated trade-off (strict FIFO is a behaviour change, not a tightening) means it needs a decision after Phase 1 lands and is measured, not a change bundled with the mechanical fix.

Tests (must fail against current main)

• The legacy fallback sorts AHEAD of every real PR — the magnitude relationship that makes an omission a bug, not a lost optimization.
• The trailing mergeable-state re-check carries the PR's createdAt and sorts by it, not the legacy base.
• The checker flags an omitting producer; a fixed-size scan window is insufficient — it must not let one producer's prCreatedAt mask a neighbouring producer's omission (verified as a real false negative while writing the check).
• The checker's own allowlist is exact-file, not a blanket exemption.

Expected outcome

Every current agent-regate-pr producer carries prCreatedAt, and CI fails the PR that introduces the next one that doesn't — closing the gap mechanically rather than requiring it to be re-found by a future audit.

[linear-code]

JSO-6598

[JSONbored]

One correction to my own issue text before anyone acts on it: I said the coalesce-key and repair-budget items "already landed independently" without having verified the coalesce claim as carefully as I should have — done now.

The coalesce-key claim in the parent (#9499) is wrong, not just already-fixed. jobCoalesceKey (src/selfhost/queue-common.ts) resolves agent-regate-pr:${repo}#${prNumber} for every agent-regate-pr message, applied centrally at send() in both queue backends (pg-queue.ts, sqlite-queue.ts) — not per dispatch call site. That key has existed since #1678, long before this audit series. So maybeEnqueueSiblingRegateForMergedPr was never missing a coalesce key; the parent's claim that it is "the ONLY wake producer in that file without one" rests on a false premise — no producer needs its own key, because the queue coalesces by message shape centrally. The "45 jobs for 15 siblings" scenario does not occur: same-repo, same-PR jobs already collapse to one row regardless of which producer sent them.

The isRegateRepairExhausted repo#pr#headSha claim, by contrast, is genuinely already fixed — confirmed directly: regateRepairTargetKey (processors.ts:1136) returns ${repoFullName}#${prNumber}, no head SHA, with a comment citing the identical fix already applied to the fresh-rebase counter.

Net: neither of the two "already landed" items in this issue's scope needs work — one was fixed, the other was never broken. Recording this so the eventual PR is not asked to explain why it touched neither.