release: move tag creation behind the release-blocker gate

Problem

The manual Release package run validates only. A maintainer then signs and pushes a v* tag, and that tag-triggered job publishes to npm and creates the GitHub Release. A blocker check after tag push is too late: the release ref already exists.

Required release-process change

• Make workflow_dispatch the canonical production release entrypoint, with version and target commit inputs.
• Run the existing validation, query open issues labeled release-blocker, and recheck immediately before the first irreversible action.
• Create the signed release tag, publish the exact npm artifact, and create the GitHub Release from the same controlled run.
• Do not rely on a GITHUB_TOKEN-created tag to trigger a second workflow; keep publication in the dispatch workflow or use a dedicated GitHub App token.
• Add an active v* tag ruleset so maintainers cannot bypass the gate by pushing release tags directly.
• Update RELEASING.md, including signing-key ownership and break-glass recovery.

Operator impact

Maintainers will dispatch one release workflow instead of validating in Actions and then running git tag/git push locally. Production tags become bot-owned; manual tag creation becomes break-glass only.

Acceptance criteria

• One open release-blocker issue prevents tag creation, npm publication, and GitHub Release creation.
• Dry-run validation remains available.
• Every independently retryable publication boundary rechecks blockers and fails closed on API errors.
• Closing or removing the label allows release.
• Direct v* tag creation is rejected for normal maintainers.