fix(queue): restore the SWEEP_MAX_PRS cap on linked-issue regate fan-out removed by #3787

[JSONbored]

Context

PR #3699 (23d85cde) added a .slice(0, SWEEP_MAX_PRS) cap to maybeReReviewOnLinkedIssueChange's fan-out (the function that re-gates every open PR linking a changed issue). PR #3787 (f15b8324), merged one day later, removed that same cap -- the function's own body now states the intent explicitly: "Remove the slice(0, SWEEP_MAX_PRS) cap ... so every open PR that links the changed issue is enqueued." The removal is currently inert (the whole function is gated behind isConvergenceRepoAllowed, and GITTENSORY_REVIEW_REPOS is empty in production), but the per-repo convergence cutover is actively rolling forward one repo at a time -- the moment the next repo lands on that allowlist, this reactivates with no ceiling.

The stagger delay (Math.min(index * 10, 600)) compounds this: past 60 fanned-out PRs, every PR beyond the 60th gets an identical 600s delay and fires simultaneously, defeating the "don't stampede the queue" protection the surrounding comment describes.

Note: the fanned-out jobs never set force/forceAiReview, so the AI-review-call cost of a large fanout is still bounded by cache for a repo with no dynamic-context feature (grounding/RAG/enrichment/etc.) enabled -- but the GitHub REST/D1/Workers-CPU cost of an unbounded fanout is real regardless, and becomes a real LLM-token cost too on any repo where a dynamic-context feature is also on.

Requirements

• Restore an upper bound on how many PRs maybeReReviewOnLinkedIssueChange enqueues per issue-change event -- either the original SWEEP_MAX_PRS cap or a deliberately-chosen (and documented) higher ceiling if fix(queue): re-gate every PR linked to changed issue #3787's intent to cover more PRs is still wanted.
• Fix the stagger so it degrades gracefully past the cap instead of saturating into simultaneous dispatch (e.g. widen the stagger window or explicitly document why saturation past N is acceptable).

Deliverables

• Updated maybeReReviewOnLinkedIssueChange in src/queue/processors.ts with a real ceiling.
• Test asserting the fan-out is capped even when a linked issue has far more open PRs than the ceiling.

Acceptance criteria

• A linked issue with 200 open PRs enqueues at most the chosen ceiling's worth of regate jobs.
• The stagger delay stays meaningfully spread across the whole enqueued batch, not just the first 60.

Parent: #1667

[linear-code]

JSO-2911

[JSONbored]

Fixed by #3960 (merged 2026-07-07), which re-added the SWEEP_MAX_PRS cap to the issue-linked regate fan-out that #3787 had removed.