Add create_release, update_release, delete_release, and generate_release_notes tools

### Describe the feature or problem you'd like to solve

The `repos` toolset can only *read* releases today (`list_releases`, `get_latest_release`, `get_release_by_tag`). There's no way for an agent to create, edit, or delete a GitHub release, or preview auto-generated release notes, without leaving the MCP flow and asking the user to do it manually in the GitHub UI. This gap covers four REST endpoints that already exist on the GitHub API:

- [Create a release](https://docs.github.com/en/rest/releases/releases#create-a-release) — `POST /repos/{owner}/{repo}/releases`
- [Update a release](https://docs.github.com/en/rest/releases/releases#update-a-release) — `PATCH /repos/{owner}/{repo}/releases/{release_id}`
- [Delete a release](https://docs.github.com/en/rest/releases/releases#delete-a-release) — `DELETE /repos/{owner}/{repo}/releases/{release_id}`
- [Generate release notes content for a release](https://docs.github.com/en/rest/releases/releases#generate-release-notes-content-for-a-release) — `POST /repos/{owner}/{repo}/releases/generate-notes`

### Proposed solution

Add four new tools to the `repos` toolset:

- `create_release` — creates a release (tag, name, body, draft/prerelease flags, make_latest, generate_release_notes, discussion category).
- `update_release` — partial update of an existing release by `release_id`, following the same "only send fields that were provided" pattern already used by `update_pull_request`.
- `delete_release` — deletes a release by `release_id` (does not delete the underlying tag), marked with the `DestructiveHint` annotation like `delete_file`.
- `generate_release_notes` — calls the preview-only generate-notes endpoint so an agent can show the user what the auto-generated notes would look like *before* committing to a release.

This lets an agent complete an end-to-end release workflow (tag → generate notes → create release → tweak → publish) entirely through MCP tools.

### Example prompts or workflows

- "Tag main as v2.3.0, generate the release notes since v2.2.0, and publish it as a GitHub release."
- "Create a draft release for v1.4.0 so the team can review the notes before it goes out."
- "Update the v1.4.0 release to mark it as the latest release and take it out of draft."
- "Delete the accidental v1.4.0-rc1 release, but leave the tag alone."
- "Show me what the auto-generated release notes would look like for v2.0.0 without creating the release yet."

### Additional context

Implementation is ready — a PR implementing all four tools (with tests, toolsnaps, and docs) follows this issue.

Start in the repos toolset and compare the existing update_pull_request and delete_file patterns with the four GitHub REST endpoints listed in the issue. Review the implementation's tests, toolsnaps, and docs, then verify that all four release workflows and the destructive-operation annotation are covered.

Vom Indexierungsmodell aus dem Issue-Text verfasst.