CI: Surface when PR descriptions mention issues that are not linked in the Development field

[adamsilverstein]

Problem

Release leads and folks writing release notes rely on the GitHub Development relationship (the linked-issues list in the right sidebar) to find every PR attached to a tracking ticket. Today, PR descriptions often mention issues (e.g. `See #1234`, `Related to #1234`, or a bare `#1234`) without actually linking them, so those PRs never show up on the referenced ticket.

Proposal

Add a non-invasive CI workflow that scans each open PR's description for issue references, compares them against the PR's `closingIssuesReferences` (the data that powers the Development sidebar), and posts an advisory sticky comment listing any references that aren't linked — with guidance on how to link them.

Requirements

• Runs on every open PR (opened, edited, reopened, synchronize, ready_for_review).
• Detects issue references in three forms: `Confirm navigation when user has unsaved changes #1234`, `Confirm navigation when user has unsaved changes #1234`, and full issue/pull URLs in this repo.
• Ignores HTML-comment placeholders from the PR template.
• Filters out references that are actually PRs or don't exist.
• Posts a single sticky comment that is updated in place and removed when everything is linked.
• Advisory only for now — does not fail the PR. Can be tightened later if it proves useful.

[kittenkamala]

This is great @adamsilverstein - Thank you so much!

[Mamaduka]

This could create a lot of noise in PRs, which already have a couple of bot comments, and I think they get ignored even then.

Referencing an issue doesn't always mean the PR resolves it; I often use it just for references. Also, while recommended, this project doesn't require every PR to have an associated issue.

I think this is worth a discussion before we merge anything. cc @WordPress/gutenberg-core

[andrewserong]

Referencing an issue doesn't always mean the PR resolves it; I often use it just for references. Also, while recommended, this project doesn't require every PR to have an associated issue.

Same, this might be a personal preference thing but the majority of the PRs I create for feature work use Related to or Part of as a means of breaking issues down into smaller PRs for implementation rather than a 1:1 relationship between issues and PRs, which can get a bit noisy for larger / higher velocity projects.

[t-hamano]

I would like to understand the background of this Issue's proposal and the specific problems that will be solved by introducing the new CI.

#77396 mentions the following:

Today, tracking tickets like the per-release editor tasks ticket rely on release leads manually following every comment and every PR mentioned in every tracker to figure out what belongs in the release

If CI is implemented, will this problem be solved? Instead of implementing a new CI, can we make better use of the project board?

Furthermore, even if the pull request doesn't actually need to close the issue, isn't there a risk that a contributor who reads the bot comments might link the pull request and the issue, causing the issue to be unintentionally closed when the pull request is merged?