Release from the GitHub UI: write the notes in a draft release, and let a workflow make the annotated tag #1680

Since #1588, a release is an annotated tag whose message is the release notes. The release workflow refuses lightweight tags, and RELEASE_MEMO.md says not to create the tag from the Releases page, because that page creates a lightweight tag.

That leaves one way to release: from a terminal, with git tag -a vX.Y.Z --cleanup=verbatim -F -. A maintainer who works from the browser can't release, and writing notes in a heredoc is less pleasant than in the release editor.

Proposal

1. The maintainer creates a draft release on the Releases page with the notes in its body, for the tag vX.Y.Z (the tag is not created yet).
2. A workflow_dispatch workflow, "Tag release", takes the version as input. It:
   • reads the draft release's body;
   • checks that the version is new and that the target commit is on master;
   • creates the annotated tag with that body as its message;
   • pushes it.
3. release.yaml builds and publishes. When it finds the draft release for the tag, it fills that release in and publishes it, instead of creating a new one.

Constraint

A tag pushed with GITHUB_TOKEN does not trigger other workflows. Either:

• "Tag release" calls release.yaml through workflow_call after pushing the tag; or
• it pushes with a GitHub App token, so the tag push triggers release.yaml as usual.

workflow_call keeps credentials simpler. The App token keeps one path for terminal and UI releases.

Acceptance criteria

• A release can be made entirely in the browser, and the result matches a terminal release: an annotated tag whose message is the notes, a published release with the built artifacts, and a PyPI upload.
• The terminal path from RELEASE_MEMO.md keeps working unchanged.
• The memo describes both paths.
• A dry-run input on "Tag release" validates without tagging.

Related

Restricting who can create v* tags with a tag ruleset is a repository setting, handled separately.