ci: automate release notes generation

[andreahlert]

Part of #715

Problem

Release notes are currently written manually by reviewing the git log between tags. This is time-consuming, error-prone (easy to miss PRs), and inconsistent in format.

Solution

Adopt a changelog fragment approach (similar to Towncrier or git-cliff):

1. Each PR that should appear in release notes includes a changelog fragment file
2. At release time, fragments are assembled into a structured changelog
3. Fragments are categorized by type (feature, bugfix, improvement, breaking change, etc.)

Options

• Towncrier: Python-based, well-established. Uses fragment files in a `newsfragments/` directory. Each fragment is named `{issue_number}.{type}.rst`.
• git-cliff: Rust-based, generates changelogs from conventional commits. No fragment files needed but requires commit message discipline.
• GitHub release notes: Built-in, generates from PR titles and labels. Least effort but least control.

Recommendation

Start with GitHub's built-in release notes generator configured via `.github/release.yml`, using our existing label taxonomy (`kind/*`) to categorize entries. This is zero-friction for contributors. Move to Towncrier later if more control is needed.

Acceptance criteria

• `.github/release.yml` configured with label-to-category mapping
• Release notes generated automatically for each tag
• Breaking changes highlighted in their own section

[andreahlert]

@skrawcz @elijahbenizzy right now releases use GitHub's auto-generated "What's Changed" list from PR titles. we could configure .github/release.yml to group entries by our kind/* labels (features, bugfixes, improvements, breaking changes). same zero effort for contributors but the output is categorized. worth setting up or is the flat list fine?

[Haricharanpanjwani]

@andreahlert I can work on this.. Do we need to get an alignment before we can start the implementation?

[andreahlert]

@Haricharanpanjwani yes, just waiting for @skrawcz and @elijahbenizzy's opinion about this.