Port filename PR identity

[lcawl]

Why

#3911 tried to fix stale CDN pool listings by bringing back changelog/{org}/{repo}/{branch}/registry.json. That approach was rejected (review): discovery should be PR-keyed GETs, not an unbounded per-branch index. That architecture is already on main (#3922–#3930).

One keep-item from that review did not land: local --prs matching must use the same identity as git-ref. Local --prs still joined only on YAML prs:. After an author strips prs: from a PR-numbered file (12345.yaml), local --prs missed it even though the file name carries the PR. CDN --prs was already fine (it probes {n}.yaml with IncludeAll).

What

Share filename PR identity with local --prs (and any matcher path that uses ChangelogEntryMatcher):

• Leading dash-separated numeric filename segments (same algorithm as git-range) or YAML prs:
• Empty/prs:-stripped {n}.yaml still matches local --prs
• Leftover hyphenated / timestamp-prefix names may also match by leading digits (git-range parity); use --files for precise path selection
• Extra PRs are scrubber markers ({n}.yaml with link: {canonical}), not combined 123-456.yaml filenames

Git-range already had this logic; it now uses the shared helper instead of a private copy.

CDN --prs is unchanged: it still probes {n}.yaml directly. This PR does not restore pool registry.json reconcile.

Generative AI disclosure

1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?

   • Yes

2. Tool(s) and model(s) used: Cursor Grok 4.5

[github-actions]

Requesting changes: filename-based --prs matching currently accepts timestamp-slug numeric prefixes, which causes mismatches against the intended behavior and documentation for PR filtering.

---

What is this? | From workflow: PR Review

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[github-actions]

ParseLeadingPrNumbers(fileName) here will treat any leading numeric segment as a PR identity before YAML prs: is considered. That makes --prs match files like 1735-foo.yaml by filename alone when prs: is empty.

This conflicts with the intended behavior documented in this PR (1735-foo.yaml should require YAML prs: or --files) and can include incorrect entries when filtering by PR.

Please constrain filename-based matching to explicit PR-style names (e.g. 12345.yaml, 12345-...) and add a negative test proving 1735-foo.yaml without prs: does not match --prs .../pull/1735.

[lcawl]

Here's the response following AI analysis:

The prefix match is real for a local directory --prs scan, but it is the same rule git-range already uses on main (ParseLeadingPrNumbers, including 1755000000-my-title.yaml). CDN --prs is unaffected: it GETs {n}.yaml and passes IncludeAll, so it never runs this filter and never sees 1735-foo.yaml.

The PR text that said timestamp-slug files need prs: or --files was wrong for that shared helper. I’ve fixed the docs to match git-range (leading numeric segments or YAML prs:). I won’t add a 12345-… allowlist or a negative 1735-foo.yaml test — that would make local --prs stricter than git-range, which this PR is not doing.

Local --prs is the only path that changes. The useful case is {n}.yaml after an author strips prs:. Scrubbed CDN copies already work via the probe key. --files remains the way to select leftover slug names precisely.

[Mpdreamz]

<c>123-456.yaml</c> that doesn't exist anymore. If a changelog has multiple PR's we create 123.yaml and 456.yaml

The later only contains:

link: 123

That way each PR can check against a known S3 location

[lcawl]

My AI analysis says the behaviour you're describing doesn't exist in main yet so I'll put this PR in draft state until the main branch stabilizes.

[lcawl]

I've rebased again now that more fixes have landed. Here's the latest response after AI analysis:

Agreed — 123-456.yaml is not how we author or store extra PRs anymore. changelog add writes one {n}.yaml per PR; after upload the scrubber adds {extra}.yaml markers with link: {canonical} so each PR has a known S3 key (#3928/#3930).

I’ve dropped that example from the helper docs and described markers instead. I’m not tightening ParseLeadingPrNumbers in this PR: git-range on main still treats leading dash-separated digits as identity (including leftover hyphenated names), and this change only shares that helper with local --prs. Changing the parser would be a git-range behavior change and is out of scope here.