ci(release): add an alpha (pre-release) dist-tag lane

[avanelsas]

What

Adds a pre-release dist-tag lane to release.yml so experimental work can ship on the npm alpha tag without moving latest. This is the one infrastructure gap the write-side alpha audit flagged: today npm publish (no --tag) would point latest at any version published, so tagging v4.0.0-alpha.0 would push the unstable write-side elements to every stable consumer.

How

The dist-tag is derived from the version in the "Derive version from tag" step:

• any semver pre-release identifier (4.0.0-alpha.0 → alpha, 4.0.0-rc.1 → rc) → that tag;
• a plain X.Y.Z (no identifier) → latest.

Four small, version-aware edits:

Step	Change
Derive version from tag	also emit dist_tag + prerelease outputs
Publish to NPM	npm publish --access public --tag "$dist_tag"
Build and Publish to Clojars	if: prerelease == 'false' — skip for pre-releases (npm/ESM-only; also avoids re-deploying an unbumped jar)
Create GitHub Release	prerelease: <bool>

Stable releases are unchanged

A plain vX.Y.Z yields dist_tag=latest, prerelease=false → npm latest + Clojars + a normal GitHub release, byte-for-byte as before. Verified the derivation locally:

3.5.0          -> dist_tag=latest prerelease=false
3.3.0          -> dist_tag=latest prerelease=false
4.0.0-alpha.0  -> dist_tag=alpha  prerelease=true
4.0.0-rc.1     -> dist_tag=rc     prerelease=true

Scope / sequencing

This PR is generic infrastructure only — it lands on main. The actual alpha publish (version bump to 4.0.0-alpha.N, tag, npm publish) happens later on the feature branch (feat/barebuild-write-side), which will merge main first so the tagged commit carries this logic. docs/RELEASING.md gains an "Alpha (pre-release) releases" section documenting the procedure. No package.json/version changes here.

Valid YAML confirmed (js-yaml).

🤖 Generated with Claude Code