ci: group generated release notes into categories

[Eliav2]

Follow-up to the release automation in #194.

publish.yml already cuts releases with gh release create --generate-notes, which is the same mechanism react-responsive-overflow-list uses. What was missing is the config that groups the output. Without it every release is one flat list, and since 25 of the last 40 pull requests are dependabot, the changes anyone actually cares about get buried.

Adds .github/release.yml with:

• ⚠️ Breaking Changes / ✨ Features / 🐛 Bug Fixes / 📚 Documentation / ⬆️ Dependencies / 🧹 Other Changes
• duplicate, invalid, wontfix and question excluded

Two deliberate choices:

Only labels that already exist on this repo are referenced. A category pointing at a label nobody applies is dead config that fails silently, which is a failure mode this repo has hit twice this week.

The dependency category matches dependencies alone, not the ecosystem labels. Dependabot applies javascript and github_actions alongside it, but a human pull request could carry an ecosystem label and would then be miscategorised as a dependency bump.

Validated against the schemastore draft-07 schema for this file.

Note

breaking-change is referenced but does not exist yet as a label. It needs creating for that category to ever match, and it is the one category the next release will actually want. Say the word and I will add the label, or add it yourself under Issues > Labels.

🤖 Generated with Claude Code

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

[coderabbitai]

Warning

Review limit reached

@Eliav2, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 23 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: dc7f01e8-3e3f-42d0-b4b7-61ab8c1a53c9

📥 Commits

Reviewing files that changed from the base of the PR and between 4c884ea and 590f454.

📒 Files selected for processing (1)

• .github/release.yml

---

_{Comment @coderabbitai help to get the list of available commands.}