Add create_release, update_release, delete_release, and generate_release_notes tools

Commencez dans le repos toolset et comparez les patterns existants de update_pull_request et delete_file avec les quatre GitHub REST endpoints indiqués dans l’issue. Examinez les tests, les toolsnaps et la documentation de l’implémentation, puis vérifiez que les quatre release workflows et l’annotation destructive-operation sont couverts.

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 — POST /repos/{owner}/{repo}/releases
• Update a release — PATCH /repos/{owner}/{repo}/releases/{release_id}
• Delete a release — DELETE /repos/{owner}/{repo}/releases/{release_id}
• 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.