Published versions appear as GitHub Releases with their changelog entry

## Summary

Create a GitHub Release from each `v*` tag, carrying the CHANGELOG section for
that version.

## Motivation

`release.yml` never creates a GitHub Release, so a published version leaves no
marker on GitHub beyond a bare tag. Someone landing on the repo can't see what
shipped when without reading `CHANGELOG.md` and correlating it with tags by hand,
and there's no feed to watch for people who want release notifications.

Cheap to add, and #161's generated changelog gives it real content: the same
generated section that lands in the release PR is the release body.

## Scope

- Add a step (or job) to `release.yml` creating the GitHub Release for the tag.
- Populate the body from the tag's `CHANGELOG.md` section.
- Decide whether it fires at candidate time as a prerelease and gets promoted, or
only once publish succeeds. Publish-time is probably right: the Release should
mean "this is on Hackage".
- Needs `contents: write`, which the workflow's current `permissions: contents:
read` does not grant — scope it to that job rather than the workflow.

## Acceptance criteria

- [ ] A published version has a corresponding GitHub Release.
- [ ] The release body matches that version's CHANGELOG entry.
- [ ] No Release is created for a tag whose publish failed.

## Additional context

- Feeds from the generated changelog in #161.

Start with release.yml and trace the existing candidate and publish steps, then inspect CHANGELOG.md and the generated changelog work referenced in #161. Implement the release only after a successful publish, with job-scoped contents: write permission, and verify that a published tag gets the matching changelog body while failed publishes do not create a Release.

索引モデルが issue の本文から書いたものです。