Add a changelog-entry CI check for user-facing PRs and automate GitHub release notes from CHANGELOG

Summary

Close two release-hygiene gaps: (1) a CI check that user-facing PRs include a CHANGELOG.md entry (with an explicit skip label for exempt changes), and (2) automation that derives GitHub Release notes from the corresponding CHANGELOG section when a release is published.

Priority: P2 · Confidence: Medium

Why this matters

The CHANGELOG is well-maintained by convention, but conventions without gates drift — one forgotten entry breaks the "track every release" promise the README makes. And today release notes are assembled by hand from a file that already contains exactly the right content; automating the copy removes release-day toil and guarantees the two never disagree.

Current evidence

• CHANGELOG.md follows Keep a Changelog with an [Unreleased] section; no CI job validates that PRs touch it (verified across .github/workflows/*.yml).
• .github/workflows/publish.yml triggers on release: types: [published] — the GitHub Release body is authored manually with no link to CHANGELOG content.
• The PR template (.github/pull_request_template.md) includes a checklist but checklists aren't gates.
• Adjacent open issue #468 (release-pipeline integrity: tag/version checks, pre-publish tests, pinned actions) is the publish-side counterpart; this issue covers the authoring side and notes generation. Coordinate so the version/tag consistency check isn't duplicated.

External context

Keep a Changelog–driven release notes extraction is a common lightweight pattern (a small script slicing the ## [X.Y.Z] section); changelog-presence checks with a skip-changelog label are standard in many OSS workflows.

Proposed implementation

1. CI job (in ci.yml): on PRs, fail if no CHANGELOG.md diff unless the PR carries a skip-changelog label; docs-only/CI-only paths can be auto-exempted by path filters (decide the exemption list deliberately).
2. Add scripts/extract_changelog.py NOTES_VERSION: print the matching CHANGELOG section; fail if missing or empty — this doubles as a pre-publish "release has notes" gate (#468 synergy).
3. Wire it into the release flow: either a small workflow that updates the GitHub Release body on publish, or a documented gh release create --notes "$(python scripts/extract_changelog.py vX.Y.Z)" step in the release procedure — maintainer preference.
4. Document the rules in CONTRIBUTING.md (when an entry is required; how to use the skip label).

AI-agent execution notes

• Inspect first: CHANGELOG.md heading format (exact anchor/dash style for parsing), ci.yml job structure, publish.yml, tests/test_check_readme_version.py for the script-test pattern.
• Run: pytest on the new extractor tests; a dry-run of the PR check logic against recent merged PRs to calibrate exemptions.
• Add tests: extractor handles current and historical sections, missing version, [Unreleased]; PR-check path filters behave.
• Edge cases: release-please-style multi-section bodies; pre-release tags; the [Unreleased] → versioned-section move at release time.
• Do not enforce retroactively or block bot PRs (exempt by author if needed).

Acceptance criteria

• A user-facing PR without a CHANGELOG entry fails CI; adding the skip label passes it.
• extract_changelog.py 0.14.0 prints exactly that release's section; missing-version exits non-zero.
• Release procedure (automated or documented) produces notes from CHANGELOG content.

Test plan

Extractor unit tests with fixture changelogs; a test PR exercising both check outcomes; one dry-run release on a pre-release tag.

Documentation plan

CONTRIBUTING.md changelog rules; release-procedure doc update (wherever #468 documents it); CHANGELOG entry (fittingly).

Migration and compatibility notes

Not expected to require migration — contributor workflow gains one labeled escape hatch.

Risks and tradeoffs

Path-based exemptions can misclassify (start permissive, tighten); label-based skips rely on maintainer discipline (visible in PR history, which is the point). Keep the extractor's parser strict about the Keep-a-Changelog format so it doubles as a format check.

Suggested labels

developer-experience, testing, documentation

Inspect CHANGELOG.md, .github/workflows/ci.yml, .github/workflows/publish.yml, CONTRIBUTING.md, and tests/test_check_readme_version.py first. Add extractor tests for versioned and missing sections, then validate the PR check and release flow; done means user-facing PRs are gated or explicitly skipped and release notes match CHANGELOG content.