Script the release notes (generated list, ledger, known issues, reporter thanks) and release creation in the release skill

[cliffhall]

Problem

Step 3 of the release skill (tag and publish the GitHub Release) is done by hand in the GitHub UI, mainly because the UI generates the "What's Changed" notes. Everything added to the notes on top of that is also manual: the smoke-ledger link, any known issues, and, since 2.9.0, credit to the people whose issues the release addresses.

What 2.9.0 proved

• GitHub's generated notes are available through the API without creating anything: POST /repos/{owner}/{repo}/releases/generate-notes with tag_name, target_commitish=main and previous_tag_name returns exactly the list the UI produces.
• A "Thanks for helping us improve" section feeds the Contributors strip. GitHub builds a release's Contributors avatars from every @-mention in the body. On 2.9.0, the six reporters mentioned in that section appeared there, alongside the PR authors.

Change

Add a scripted notes-and-release step to the release skill, as a tested scripts/ helper:

1. Generate the What's Changed list with releases/generate-notes (previous tag to main).
2. Append the smoke-ledger line: Smoke test ledger for milestone branch: [<merge branch>](<ledger url>).
3. Append a ## Known issue(s) section when there are any, from a list the maintainer passes in, since what counts as a known issue is a judgment call.
4. Append ## Thanks for helping us improve:
   • For each PR in the generated list, take the issue(s) it closes: the manual closing links (closingIssuesReferences) plus Closes/Fixes/Resolves #N in the body.
   • Credit each issue's author, excluding maintainers (repo permission admin, maintain or write) and bots.
   • One line per person, most issues first: * @user (#1, #2, …).
   • Lead-in: "This release addresses issues reported by these community members. Thank you for taking the time to file them:". Use "addresses", not "fixes", because feature requests are included.
   • Omit the section when no community reporter remains.
5. Create the Release with gh release create <x.y.z> --target main --notes-file …. That fixes the bare tag (no v) and the main target by construction, which is exactly what the skill's manual steps warn about getting wrong.

Publishing stays a deliberate maintainer action. Publishing the Release triggers package → publish (npm) and the GHCR image. The helper can create the Release as a draft for review, or publish on an explicit flag, but it never publishes implicitly.

Notes

• Editing a published release's body is safe: every tag's main.yml triggers only on release: types: [published] (checked from 2.0.0 through 2.9.0), so edited never re-runs publishing.
• Offer a preview mode that prints the assembled notes without creating anything.

Acceptance

• scripts/release-notes.mjs (or similar) assembles the notes, with a sibling *.test.mjs covering the issue-author mapping and the exclusions
• The release skill's step 3 uses it, with draft-then-publish as the default
• A dry run against 2.9.0 reproduces its published notes

[cliffhall]

Triage: Priority Medium (total 7)

• Severity 2 — a manual release step with an easy workaround (the GitHub UI)
• Urgency 4 — wanted for the next release, so v2.10.0 ships with it
• Bonuses: +1 milestoned (v2.10.0)

Board: #28, Status Todo.

[cliffhall]

Requirement from the Copilot review of #2555 (the recipe this helper replaces): the helper must fail fast on any API error. That means checked gh calls and pipefail, and never mapping a failed permission lookup to "community" (which could credit a maintainer) or silently dropping PRs or issues on a rate limit. A partial Thanks list must abort note generation, never publish.

[cliffhall]

Second requirement from #2555's review: paginate closingIssuesReferences (pageInfo / endCursor) instead of a fixed first:N. Today no PR comes close (the most manual closing links on any of the last 100 merged PRs is 2), but a tested helper should be exhaustive by construction.