fix(orb): fork-PR CI-completion coalescing skips the durable cache invalidation it's supposed to guarantee unconditionally

[JSONbored]

⚠️ Definition of Done: this issue must be completed in full, in a single PR. Do not split this
work across multiple PRs, and do not defer any Deliverable below to a follow-up issue. A PR that
satisfies only some of the Deliverables, stubs a required test, or leaves a checkbox
partially-done does NOT resolve this issue and will be closed.

Context

src/queue/processors.ts:4576-4591's maybeReReviewOnCiCompletion returns early via
ciHeadShaResolutionCoalesced for fork PRs (identified by an empty pull_requests[] in the webhook
payload) before ever reaching the durable-cache invalidation loop at lines 4614-4632. That loop's
own comment (lines 4615-4618) states it invalidates the cache "for EVERY resolved PR, regardless of
whether the re-review below actually fires" — i.e. it's meant to be unconditional.

For same-repo PRs, the coalescing check happens after cache invalidation, so invalidation always
runs. For fork PRs, once one completion event in a burst gets coalesced (its own 60-second dedup
window), the function returns before invalidation ever executes.

Consequence: of the roughly 20 completion events a single CI run fires for a fork PR's head SHA,
only the first one per 60-second coalescing window invalidates the durable cache — every later
completion event in the same burst is silently dropped without invalidating, so a reader can observe
a stale, pre-completion CI aggregate for up to the cache TTL, for fork PRs specifically (same-repo
PRs are unaffected).

Requirements

• Move the cache-invalidation call so it runs unconditionally for every resolved completion event —
  before the fork-PR coalescing early-return — matching the comment's own stated intent and the
  same-repo code path's existing (correct) ordering.
• Do not change the coalescing logic itself (it should still suppress the actual re-review dispatch
  for fork PRs the same way it does today) — only ensure invalidation isn't skipped alongside it.

Deliverables

• Cache invalidation runs for every resolved fork-PR completion event, even when the re-review
  dispatch itself is coalesced away.
• A new test fires two check_run/check_suite completion events within the coalescing window
  for the same fork PR head SHA, with differing CI state between them, and asserts cache
  invalidation happens on both events — currently only the first.
• A regression test confirms the coalescing logic still correctly suppresses a duplicate
  re-review dispatch for the second event (proving the fix doesn't remove the intended
  deduplication of the re-review itself).

All three Deliverables are required in the same PR.

Test Coverage Requirements

src/** is measured by codecov/patch (99%+ target, branch-counted). The new tests must exercise
the fork-PR coalescing-plus-invalidation interaction directly, which has zero coverage today for the
divergent (invalidation-skipped) case.

Expected Outcome

Fork PRs get the same unconditional cache-invalidation guarantee same-repo PRs already have,
eliminating a stale-cache window that can persist for up to the cache TTL after a CI completion
burst.

Links & Resources

• src/queue/processors.ts:4576-4591 (maybeReReviewOnCiCompletion,
  ciHeadShaResolutionCoalesced), :4614-4632 (the invalidation loop and its "for EVERY resolved
  PR" comment)

[linear-code]

JSO-6029