ci: make merging a version bump the whole release

[saby1101]

Replaces the manual tag push and hand-created GitHub Release. Merge this before the 2.16.0 bump (#24) — see ordering below.

How it works

release.yml runs on every push to main. If package.json's version has no matching vX.Y.Z tag, it runs the full gate — lint, build, unit tests, MinIO integration — then tags, creates the GitHub Release with generated notes, and publishes.

Releasing becomes: branch → pnpm version → PR → merge. Nothing manual after that.

Why one workflow, not two

The obvious design is "workflow creates the release, release: published publishes it". That does not work: a release created with GITHUB_TOKEN does not trigger further workflow runs — GitHub blocks it to prevent recursion. The publish job would simply never fire.

That is the same silent-no-publish failure mode as the created/published trigger bug, so npm-publish-github-packages.yml is replaced rather than kept alongside — two publish paths where one silently does nothing is worse than one.

Safety

• Ordinary merges do not publish. The version is almost always already tagged, so the check job exits early. Merging this PR is itself the first test of that: main is at 2.15.0, v2.15.0 exists, so the workflow should no-op.
• Idempotent. Tag, release and publish steps each skip work already done, so workflow_dispatch retries a failed run without another version bump.
• Gate before publish. Publishing is irreversible, so lint, build, unit tests and the real-MinIO integration suite all run first.
• No injection surface. The only interpolated values are github.event_name (a fixed enum) and the version read from package.json, passed through env.
• Duplicate versions 409, which is the failure we want if something goes wrong.
• Tag creation is permitted: the org tag ruleset (stackbox-standard-tags) blocks only deletion and non-fast-forward.

Docs

CONTRIBUTING.md, CLAUDE.md and .claude/skills/release/SKILL.md now describe the real flow. They previously said "do not create tags by hand — creating the GitHub Release creates the tag", which was my error: it did not match the pnpm version practice actually in use, and is now superseded anyway.

Ordering

1. Merge this → main still at 2.15.0, v2.15.0 already tagged → workflow no-ops. Confirms the guard.
2. Merge 2.16.0 #24 (the 2.16.0 bump) → no v2.16.0 tag → full gate, tag, release, publish.

Merging them the other way round would have #24 land with no release workflow present, back to a manual tag push.

Verification

YAML validates; jobs check and release; triggers push + workflow_dispatch; permissions contents: write, packages: write. Lint, build and prettier --check clean.

The workflow itself cannot be fully exercised until it runs — which is why step 1 above is a real no-op test rather than a formality.