Add kind/breaking label for breaking changes in release notes (#79)

Breaking changes are currently invisible in the generated release notes:
they land in Features or Refactors like any other PR. Add a dedicated
kind/breaking label and a "Breaking Changes" section.

- release.yml: the section is listed FIRST, so a PR that is both a feature
  and a breaking change surfaces as breaking. GitHub's release-notes config
  is static and cannot key off the version being cut, but the section is
  self-gating: it only renders when a PR in the range carries the label.
- labels.sh: kind/breaking in red (b60205) rather than the kind/* blue, so
  it stands out on the PR list. The older unnamespaced "breaking change"
  label is left untouched.
- pull_request_template.md: note that a breaking change belongs in a major
  release and that the PR summary should describe the upgrade path.

Labels are not synced automatically — run .github/labels.sh after merge.

Author: Mark90

.github/labels.sh

@@ -23,7 +23,13 @@ set -euo pipefail
 # documentation, ...):
 #   kind/*  -> blue    (0052cc)
 #   exclusion marker -> grey (ededed)
+#
+# kind/breaking is the one deliberate exception: red (b60205), because it is the
+# label a reviewer most needs to spot on a PR list. Note the repo also has an
+# older, unnamespaced "breaking change" label in the same red; that one is left
+# alone here — kind/breaking is the one that drives the release notes.
 labels=(
+  "kind/breaking|b60205|Breaking change — requires action from users when upgrading"
   "kind/feature|0052cc|New user-facing functionality"
   "kind/bug|0052cc|A confirmed bug fix"
   "kind/refactor|0052cc|Internal refactor with no behavior change"

.github/pull_request_template.md

@@ -12,8 +12,13 @@ Set a label on this PR so it is categorized in the release notes. This is
 required — the "require-release-label" check fails without one.
 Some labels (kind/documentation, kind/test, kind/ci, kind/build) are applied
 automatically from the files you changed; set the rest yourself.
+
+A PR lands in only the FIRST matching release-notes section, and Breaking
+Changes comes first — so a breaking feature is listed there rather than under
+Features. That is intended: it is the section people read when upgrading.
 -->
 - [ ] I have set a `kind/*` label describing the change (e.g. `kind/feature`, `kind/bug`, `kind/refactor`), or `skip-changelog` if it should be left out of the notes.
+- [ ] If this is a breaking change, I have set `kind/breaking`. Breaking changes belong in a **major** release, and the summary above should describe what users must do to upgrade — it ends up in the release notes.
 
 ## Checklist
 

.github/release.yml

@@ -13,6 +13,17 @@ changelog:
     labels:
       - skip-changelog
   categories:
+    # Breaking Changes is deliberately first. A breaking change is often also a
+    # feature or a bug fix, and since a PR lands in only the FIRST matching
+    # category it is listed here instead of there — that is the section readers
+    # of a major release need to see, and it keeps it from being buried.
+    #
+    # There is no way to make a category depend on the version being released:
+    # .github/release.yml is static config. The section is self-gating instead —
+    # it only appears when a PR in the release range carries kind/breaking.
+    - title: ⚠️ Breaking Changes
+      labels:
+        - kind/breaking
     - title: 🚀 Features
       labels:
         - kind/feature