fix(ci): releasable-commit-types:check flags release-please's own release commit as stranded

[JSONbored]

Problem

releasable-commit-types:check fails on every release-please release PR, flagging release-please's own release commit as a stranded change.

Reproduced on #10283 (chore(release): cut ui-kit v1.7.0):

These commits change published package source under a commit type release-please treats as invisible,
so the change would merge green and then never reach npm:

  54e2df7e chore(release): cut ui-kit v1.7.0
      packages/loopover-ui-kit/package.json

The claim is exactly backwards. That commit is not a change that will never reach npm — it is the commit that performs the release. release-please writes it, tags it, and publishes from it.

Why it fires

publishedSourcePrefixes (scripts/check-releasable-commit-types.ts:60-64) includes <pkg>/package.json for every released package. A release commit's whole job is to bump the version field in exactly that file, and release-please writes it under chore(release): — a type in the hidden set. So the guard matches by construction on every release PR it will ever see.

findStrandedCommits (line 87) already carries three exemptions — Release-As: footer, breaking-change !, and test files — and none covers this case.

Why it matters

The check's own docstring makes the argument better than I can (line 69):

a guard that fires on the ordinary case is a guard that gets disabled

A release PR is the most ordinary case there is. Left alone, every future release PR ships with a red drift-checks-history, and the failure that this check exists to catch — a real chore: commit stranding published source, the #10118-class bug where ui-kit sat unreleased for weeks — becomes indistinguishable from the routine noise.

It also breaks the "green before merge" posture on the one PR type nobody hand-writes: a maintainer cannot fix it by rewording the commit, because release-please generates it.

Why nobody noticed until now

The drift-checks-history job is needs: changes and does not run on every release PR — on #10283 it only fired after main was merged into the branch to clear a conflict, which widened the change set enough to trigger the job. So the bug has been latent, not absent: it fires whenever that job happens to run on a release PR.

Deliverable

• Exempt release-please's own release commits in findStrandedCommits. The narrow, source-of-truth-respecting form: a commit is exempt when its only matching published-source paths are <pkg>/package.json files whose diff touches nothing but the version field. A blunter chore(release): subject match would also work but is weaker — it would exempt a hand-written commit that happens to borrow the subject.
• Prefer deriving the release-commit shape from release-please-config.json where possible, per the file's existing "the config is the source of truth, not a list here" rule (line 23).
• Unit tests both ways: a genuine release commit passes; a chore: commit that changes <pkg>/package.json beyond the version field (a dependency edit, an exports change) is still flagged.
• Verify against chore(release): cut ui-kit v1.7.0 #10283's actual head — the check must go green on it without the release branch being touched.

Acceptance

releasable-commit-types:check passes on a release-please release PR and still fails on the stranded-source case it was built for, with tests pinning both.

[linear-code]

JSO-7169