ci: grade only open pull requests, for every caller at once

[Kartikey1306]

The Linked issue policy caller in every consuming repository runs on pull_request_target for [opened, edited, reopened, synchronize]. edited fires on closed and merged pull requests too, so a body edit on a PR merged before the policy existed grades it against the policy and fails it. On 2026-09-14 a bulk body edit did exactly that to roughly fifty merged PRs across eos, eBoot and ebuild. A merged PR cannot be changed to satisfy anything, and grading it says nothing about the tree.

Why here and not in the callers

This guard was first proposed one caller at a time — eBoot#125, ebuild#144, eos#154. The automated review of eBoot#125 hashed the caller across the org and found it byte-identical in nineteen repositories, not three, and asked for the fix to live in this reusable workflow instead. That is right: the github context inside a reusable workflow is the caller's, so github.event.pull_request.state here reads the caller's event, and one line covers every consumer once its uses: pin bumps to this commit — which Dependabot already does org-wide.

Change

jobs:
  linked-issue:
    name: Policy / Linked Issue
    if: github.event.pull_request.state == 'open'

with a comment saying why. Only an open PR is a decision still to be made.

What it does not change. Open PRs still see the guard as true, so the policy keeps running on every PR that can still be acted on. Nothing is weakened.

Verified

From the parsed document, not from parse success:

$ python -c "import yaml; d=yaml.safe_load(open('.github/workflows/linked-issue-policy.yml')); j=d['jobs']['linked-issue']; print(j['if']); print(j['runs-on']); print(list(d[True]))"
github.event.pull_request.state == 'open'
ubuntu-latest
['workflow_call']

policy_ref input and its immutability check are untouched.

NOT RUN: a live pull_request_target: edited event on a merged PR against this ref — that needs a consumer to bump its pin first. The three caller-side PRs above carry the identical expression and were verified against the 13 real failing runs in eBoot, each resolved to a merged or closed PR.

Once this lands and pins bump, eBoot#125 / ebuild#144 / eos#154 become redundant and can be closed; until then they are the only guard those three repos have.

[Kartikey1306]

Closing in favour of #9, opened one minute earlier by a parallel session working the same bot finding (eBoot#125 / eos#154).

Compared head-to-head before closing, not on the summary:

	#9 (5a4456a)	#10 (50bf025)
guard on jobs.linked-issue	if: github.event.pull_request.state == 'open'	byte-identical
tests/community/test_linked_issue.py	+29: asserts the guard is on the job, and that no step carries one	none

#9 has everything #10 has plus the structural test that proves the guard is where it must be — a later edit that moved the if onto a step (where it would no longer skip the job) fails #9's test and nothing in #10 would notice. Nothing in #10's diff is absent from #9.

One line from #10's body worth carrying over if #9's lacks it: a live pull_request_target: edited event on a merged PR cannot be exercised by a PR against this repo — pull_request_target runs the workflow from the base branch — so it is NOT RUN here, and the evidence is the 13 real failing runs in eBoot each resolved to a merged or closed PR.

Same cause as the duplicate it fixes: two sessions acted on one finding in the same minute without gh pr list --repo embeddedos-org/.github --state open first.