Section the auto-generated release notes by label

[albertvillanova]

This PR adds .github/release.yml so the release notes GitHub drafts come out already split into sections, instead of one flat list.

Motivation

Every release so far has been written by hand on top of a flat "What's Changed" list, and the resulting notes have used the same sections since v1.9: Breaking, Features, Fixes, Documentation, CI. GitHub can produce that split itself from a label to section mapping.

Solution

The section titles match the ones the recent releases already use, so the draft lands shaped like the final notes and the remaining work is promoting entries into hand-written subsections rather than sorting them.

Three of the labels already exist (✨ enhancement, 🐛 bug, 📚 documentation), and Dependabot already applies dependencies to all of its PRs, so that section works with no extra effort. Two labels do not exist yet and are listed below as a blocker.

An unlabelled PR falls into Other, which is what the flat list gives today, so nothing regresses while labelling ramps up.

Priority labels such as 🩹 for patch are deliberately left out: they mark a different axis, and since a PR lands in the first matching category they would pull PRs out of the section that describes what actually changed.

Changes

• Add .github/release.yml mapping labels to release notes sections
• Other is the catch-all and stays last, since a PR lands in the first category whose labels match

Before merging

• Create the 💥 breaking label: breaking change, removal, or deprecation
• Create the 🔧 maintenance label: CI, tooling, tests, or repo upkeep

---

Note

Low Risk
Adds GitHub release-notes configuration only; no runtime or application code changes.

Overview
Adds .github/release.yml so GitHub’s auto-generated release notes draft is grouped into sections (Breaking, Features, Fixes, Documentation, CI and maintenance, Dependencies, Other) instead of a single flat list.

Each section maps to existing or planned PR labels (e.g. ✨ enhancement, 🐛 bug, dependencies); unlabeled PRs land in Other via the catch-all * label, which must remain last because GitHub assigns each PR to the first matching category.

^{Reviewed by Cursor Bugbot for commit b95db9a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bot-ci-comment]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[qgallouedec]

Only one label is actually missing: it seems that you created 🔧 maintenance already , so it's just 💥 breaking to create.

LGTM otherwise, and agreed on leaving 🩹 for patch out, it's a different axis.

I guess we will have to label our pr properly now, right?

[albertvillanova]

Yes, but only for about half of them.

Of the last 300 merged PRs, 47% touch trl/, and there the question is feature or fix, which needs a human. The rest is mechanical: infra only 31%, tests only 12%, docs only 4%.

So I will open a follow-up wiring actions/labeler for 📚 documentation and 🔧 maintenance only, leaving ✨ enhancement, 🐛 bug and 💥 breaking to us.

And yes, I will create 💥 breaking before merging.