ci(release): manual workflow_dispatch release pipeline

[protonspy]

Summary

Makes shipping a new version a deliberate, manual action. The release workflow no longer fires on push (tag or main) — it runs only via workflow_dispatch, takes the version as an input, and runs the complete pipeline end-to-end.

How to release now

From the Actions tab → release → Run workflow (enter vX.Y.Z), or:

gh workflow run release.yml --field version=v0.1.3
# convenience wrapper:
make release VERSION=v0.1.3

Pipeline (one manual run)

validate version → CI gate (Go + mcp-server tests) → cross-platform binaries → publish all 7 npm packages (launcher + 5 platform binaries + csdd-mcp, same version) → tag the commit + GitHub Release.

Changes

• .github/workflows/release.yml
  • on: push (main + tags) → on: workflow_dispatch with a required version input.
  • Dropped the rolling "latest" pre-release (it was the only thing tied to main pushes; releasing is now fully manual).
  • Version flows from the input (passed via env vars to avoid shell injection); a validate job rejects anything that isn't vX.Y.Z.
  • The tag + GitHub Release are created only after npm publish succeeds (release needs npm-publish), so a failed publish never leaves a dangling tag/release.
• Makefile — make release VERSION=vX.Y.Z now dispatches the workflow (gh workflow run release.yml --field version=…) instead of pushing a tag.

Notes

• make release / gh workflow run release.yml only work after this PR merges (a workflow_dispatch workflow must exist on the default branch to be dispatchable).
• The npm publish still needs NPM_TOKEN to be an Automation token (otherwise it fails with EOTP, as the v0.1.2 attempt did).

🤖 Generated with Claude Code