gate: a PR superseded by a merged rival is reported as "No linked issue detected"

[JSONbored]

A superseded PR is reported as "No linked issue detected"

JSONbored/metagraphed#8886, live right now:

PR 8886 opened	09:22:36, linking issue #8829
Issue #8829 closed	09:30:25, by loopover-orb[bot] — a competing PR merged and closed it
8886's verdict	hold / missing_linked_issue, manual-review label, still open, CONFLICTING

The contributor is told:

No linked issue detected — The PR cites an issue number, but it could not be verified as a currently open issue.
If this PR is intended to solve an issue, link it explicitly in the PR body.

They did link one, correctly. The truth is "someone else already fixed this while you were working" — and the advice given is impossible to act on: re-linking the same (now closed) issue changes nothing.

Why it lands there

confirmedNoOpenLinkedIssue (#unlinked-issue-guardrail-followup) exists to stop a contributor satisfying linkedIssueGateMode: block by citing an already-closed or fabricated issue. That is a real countermeasure and should stay.

But it cannot distinguish two very different situations:

1. Gaming — the PR cited a stale/dead issue to clear the gate. The countermeasure's target.
2. Superseded — the PR linked a genuinely open issue, and that issue was closed after the PR opened, by a different PR that merged first. Ordinary contributor collision.

Both collapse to missing_linked_issue. The second is not a linking failure at all.

Why this matters beyond the wording

• The advice is unactionable. The suggested remedy cannot resolve the state.
• The disposition is wrong. A superseded PR should be recognised as superseded — the work is already done — not held for a maintainer to interpret. fix(services): remediation-plan.ts's forbidden-word regex fails to catch the plural "rankings" #8886 is additionally CONFLICTING, which it would be, since the merged rival touched the same code.
• Duplicate detection cannot see it. The duplicate/overlap machinery keys on open sibling PRs sharing a linked issue. Once the rival has merged it is no longer an open sibling, and the issue is closed, so the overlap that actually happened is invisible by the time it matters.
• It wastes the contributor. They are told to fix a linking mistake they did not make.

The distinguishing signal is available

The two cases are separable with data already at hand:

• was the linked issue open when the PR was created, and closed later? (issue closed_at vs PR created_at)
• was it closed by a merged PR, rather than manually? GitHub's timeline names the closer

Both true ⇒ superseded, not gaming. That should produce its own finding — "the issue this PR targets was closed by another merged PR" — with a disposition that says so, rather than reusing missing_linked_issue.

Suggested scope

A distinct finding code and message for the superseded case, keeping confirmedNoOpenLinkedIssue's anti-gaming behaviour intact for the case it was built for. The disposition for a superseded PR (close as superseded vs hold with an accurate reason) is a policy call worth deciding explicitly rather than inheriting from the linked-issue gate.

Found while auditing why PRs still carry manual-review after #10116/#10164.

[linear-code]

JSO-7101