GitHub Release creation is duplicated, and the Fallout-native target never runs

### Problem

`publish-packages-release.yml` creates GitHub Releases with a shell call to `gh release create`. A Fallout target for the same job already exists — `ICreateGitHubRelease.CreateGitHubRelease` in `build/Build.cs:184` — and it never runs. Its two conditions cannot both be true: it is `TriggeredBy`, but gated to the `publish-packages-release` workflow, and that workflow runs `dotnet fallout Test Pack`, never `Publish`.

Two consequences:

- The target builds its release body from the milestone's closed issues. That code is dead. It was written for this fork on purpose (`build/Build.cs:180-183`), because the base implementation reads `CHANGELOG.md`, which this repo no longer has.
- The shell fallback calls `gh release create --generate-notes` with no `--notes-start-tag` (`.github/workflows/publish-packages-release.yml:278-282`). `gh` then anchors the notes on the most recent tag. For a release candidate that is the previous release candidate, so the notes only cover the few commits between them. Maintainers create the release by hand to pass the right anchor, and [docs/branching-and-release.md](https://github.com/Fallout-build/Fallout/blob/main/docs/branching-and-release.md) documents that as a required step.

### Outcome

A maintainer pushes a tag. CI produces a GitHub Release with notes covering everything since the last GA. The runbook has no hand-written `gh release create` step.

### Acceptance criteria

- [ ] Pushing a `v*` tag produces a GitHub Release whose notes start from the last GA, not from the previous prerelease
- [ ] `ICreateGitHubRelease.CreateGitHubRelease` either runs, or is deleted
- [ ] Checked for both a prerelease tag and a GA tag
- [ ] The manual release-creation step is removed from `docs/branching-and-release.md`

### Notes

The release lane cannot just run `dotnet fallout Publish` today. Its three publish jobs each bind a separate GitHub Environment (`nuget-org`, `github-packages`, `github-releases`) for approval gating. A GitHub Environment is scoped to one job, so a single build target cannot fan out across all three. Fixing that is the scope of #498 (the `IPublishTarget` / channels / environments model, ADR-0009), so this work belongs there.

Not for 10.4 — 10.4.0 is being cut by hand.