Add one-click release workflow to prevent tag/version drift

[ejntaylor]

Why

The Publish workflow rejected v0.3.3 because the tag (0.3.3) didn't match package.json (0.2.11) — the second time this has happened. Root cause: tags are created by hand, decoupled from the package.json bump, so they can drift from the version that actually gets published.

What

• .github/workflows/release.yml — a dispatch-driven Release workflow (Actions → Release → Run workflow). Pick patch/minor/major or type an explicit version; it runs npm version to bump + commit + tag, then pushes, publishes to npm (with provenance), and cuts the GitHub release — all from one number. Because the tag is derived from npm version, it can never disagree with package.json.
• RELEASING.md — documents the one-click path and the manual fallback rules.

The existing publish.yml is untouched: its guard stays as a safety net for hand-made releases, and it won't double-publish (releases created by release.yml use GITHUB_TOKEN, which doesn't re-trigger the release: published event).

Note

This does not itself fix the in-flight v0.3.3 failure — main has diverged from the pulse-protect-node-waf branch that shipped 0.3.0–0.3.2, so the correct source/version for 0.3.3 needs a human call before re-cutting.

🤖 Generated with Claude Code

[coderbuds]

Clear and robust one-click release workflow preventing version drift.

🎯 Quality: 99% Elite · 📦 Size: Medium

📈 This month: Your 215th PR — above team average · Averaging Excellent

_{See how your team is trending →}

[ejntaylor]

/review