feat(review): event-driven re-gate trigger on sibling PR merge

[JSONbored]

Context

Companion to the merge-train gate (see the FIFO merge-ordering issue). When a PR merges, no code path proactively re-checks the repo's other open PRs for a newly-introduced conflict — everything downstream is either time-polled (the sweep, bounded by SWEEP_MAX_PRS = 3 per repo per ~2-minute tick) or externally triggered (a fresh webhook on that specific PR). A sibling PR can sit with a stale, wrong gate verdict for a full sweep cycle or more after a merge invalidates it.

Requirements

1. React to a pull_request webhook with action === "closed" and merged === true by enqueuing an agent-regate-pr job for the repo's other open PRs (reuse the existing job type and dispatch machinery — this is new enqueuing logic, not a new job type).
2. Bound the fan-out (cap the number of siblings re-gated per merge event, mirroring existing caps like listOtherOpenPullRequests's 100-row limit) so a repo with many open PRs doesn't create an unbounded burst.
3. This should ship independently of and before the merge-train gate — it closes the "stale sibling" gap regardless of whether merge-train ships, and reduces the number of genuinely-conflicted merges that slip through in the meantime.

Deliverables

• New enqueue logic triggered from the pull_request.closed (merged) webhook handler in src/queue/processors.ts.
• Test coverage for the fan-out cap and the merged-vs-just-closed distinction (only a real merge should trigger this, not an ordinary close).

Expected outcome

A PR invalidated by a sibling's merge gets its gate verdict refreshed within the normal per-PR job latency (seconds/low minutes) instead of waiting for the next sweep cycle to notice it's stale.

[linear-code]

JSO-3129