feat(release): generate rich release notes from milestone + auto PR list

[ChrisonSimtian]

Summary

The first release (`10.2.0`, just merged) shipped with an empty body because the base `ICreateGitHubRelease` implementation reads from `CHANGELOG.md`'s `[vNext]` section, which we don't maintain.

Replaces that with a milestone-aware release-notes builder that produces something actually useful.

What changes in the release body

For each release tag pushed to main, the generated GitHub Release now contains:

1. Milestone header — linked title of the milestone whose name starts with the release version (matches our `"10.2.0 - "` convention).
2. Pull requests in this milestone — grouped list with PR number + author.
3. Issues closed in this milestone — grouped list.
4. Auto-generated diff — GitHub's native `generate_release_notes` appends the full PR-since-last-tag list. Covers anything that wasn't attached to a milestone.

Each milestone item also gets a "Released in vX.Y.Z! 🎉" comment, same as before — but the milestone-lookup is now prefix-matched instead of requiring an exact `v10.2.0` title.

Why not inherit the base

The base `.Inherit()` always runs first and creates the release with the CHANGELOG body. Then our override would add to it. To replace the body entirely, we own the create-release call directly. Octokit usage is consistent with the rest of `Build.cs`.

Test plan

• `dotnet build build/_build.csproj` — 0 errors
• Next release to main (`10.2.1` or whatever git-height produces) shows the rich body
• Milestone-item comments still fire

Follow-ups

• `MajorMinorPatchVersion` still uses GitVersion. Now that Nerdbank drives versions, should switch to reading from there for consistency.
• Once the project rename happens and we have labels, can configure `.github/release.yml` to group GitHub's auto-generated list by category (Features / Bug fixes / Chore).

🤖 Generated with Claude Code