ci: automate release notes and PR labeling

[dcalhoun]

What?

Adds GitHub configuration and documentation to automate release notes generation and PR labeling based on Conventional Commits.

Why?

Release notes were noisy — Dependabot dependency bump PRs dominated the changelog, making it hard to see meaningful changes. There was also no consistent labeling of PRs by type, and the commit/PR conventions lived only in AGENTS.md (AI agent guidance) rather than human-facing docs.

How?

• .github/release.yml: Configures GitHub's automatic release notes to exclude Dependabot PRs and group changes into four categories — "Breaking Changes", "Features & Enhancements", "Bug Fixes", and "Other Changes" — using existing repository type labels. Noise labels ([Type] Automated Testing, [Type] Build Tooling, [Type] Task, [Type] Developer Documentation, dependencies) are excluded from "Other Changes" to keep the changelog focused on user-visible changes.
• .github/workflows/label-pr.yml: On PR open or edit, parses the Conventional Commits prefix and breaking change indicator (!) from the PR title and applies the matching repository label. When ! is present (e.g. feat!:, fix(scope)!:), only [Type] Breaking Change is applied. Skips if a conflicting type label is already present, so developers can override the auto-assigned label.
• bin/release.sh: Release commits now follow the Conventional Commits format (chore(release): x.y.z).
• docs/code/developer-workflows.md (new): Human-facing documentation covering Conventional Commits usage, PR guidelines, and the automatic labeling rules.
• docs/releases.md: Added a "Release Notes" section explaining category groupings, Dependabot exclusions, and linking to the labeling rules.
• docs/code/README.md: Linked to the new developer-workflows.md.
• AGENTS.md: Replaced inline commit/PR guidelines with a pointer to the new doc.

Conventional Commits → label mapping:

Prefix	Label
feat	[Type] Enhancement
fix	[Type] Bug
perf	[Type] Performance
test	[Type] Automated Testing
docs	[Type] Developer Documentation
build, ci	[Type] Build Tooling
refactor, task, chore, style	[Type] Task
any type with !	[Type] Breaking Change

Testing Instructions

We can forgo testing for now, as the changes will not take effect until they are merged.

Accessibility Testing Instructions

N/A — no UI changes.

[nbradbury]

@dcalhoun This looks good, but I should mention that Claude found one potential issue (which most likely isn't a problem):

Dependabot's GitHub actor is dependabot[bot]. Some repos need to use that full name for the exclusion to match. I'd verify this works as-is, or change it to dependabot[bot] to be safe.

Also, can you clarify what is meant by, "Creating a release and confirming Dependabot PRs are excluded?" If this means a signed release build I don't believe I'm able to do that.

[dcalhoun]

@dcalhoun This looks good, but I should mention that Claude found one potential issue (which most likely isn't a problem):

Dependabot's GitHub actor is dependabot[bot]. Some repos need to use that full name for the exclusion to match. I'd verify this works as-is, or change it to dependabot[bot] to be safe.

@nbradbury thanks for sharing. I was unable to find definitive documentation on which name is correct. I ultimately excluded both in bb3c820 to be sure.

I add a few additional changes as well:

• 48394dd - separate breaking changes in the release notes
• 3e5c429 - further reduce release notes noise by excluding non-feature/bug changes
• a9c2dfc - use Conventional Commits spec for the ./bin/release.sh script commits

Also, can you clarify what is meant by, "Creating a release and confirming Dependabot PRs are excluded?" If this means a signed release build I don't believe I'm able to do that.

I meant creating a new release via the project's ./bin/release.sh script. We should not do so now. We'll see if these changes work as expected for the next release. Sorry I did not clearly communicate that we can forgo testing now.

[nbradbury]

@dcalhoun I'll approve this but wanted to mention a couple of items Claude suggested upon re-review:

1. Missing "Breaking Changes" in docs/releases.md — The release notes section lists three categories (Features & Enhancements, Bug Fixes, Other Changes) but omits "Breaking Changes", which is the first category in .github/release.yml. The docs are inconsistent with the config.
2. Missing ! breaking change convention in docs/code/developer-workflows.md — The labeling workflow supports the ! indicator (e.g., feat!:, fix(scope)!:) and maps it to [Type] Breaking Change, but the developer-facing documentation doesn't mention this convention at all. Developers won't know how to signal a breaking change.

[nbradbury]

Looks good!