Make the release tag the source of truth for the version

[joehoyle]

Cutting a release currently means a package.json bump PR, a tag that must match it exactly, and a GitHub Release on top. The workflow refuses to publish if the tag and package.json disagree. The 1.1.1 release stalled on exactly this, and the bump PR (#50) was where the duplicate scripts key crept in that took CI down for three days. The version bump is pure ceremony that creates opportunities for mistakes and nothing else.

This makes the release tag the single source of truth. The workflow validates the tag is semver (a leading v is accepted and stripped), writes it into package.json with npm version, and publishes. package.json in git holds a 0.0.0-development placeholder, so nobody touches it for releases again. Cutting a release is now: draft a GitHub Release, type a new tag name, generate notes, publish.

Alternatives considered:

• Release Please / Changesets. Gives a maintained CHANGELOG, but reintroduces an automated bump PR and needs conventional-commit discipline across every contributor, including AI-authored PRs. GitHub's generated release notes cover this repo's needs.
• A dispatch workflow that runs npm version and pushes to main. Needs a token that bypasses branch protection and races with concurrent merges.

Trade-off: altis-cli --version from a git clone reports the placeholder. Installs from npm, which is how anyone actually uses this, report the real version. Provenance is unaffected since npm reads the version from the tarball.

Verified locally that the tag regex accepts 1.2.0, v1.2.0 and 1.2.0-beta.1 and rejects release-1.2, and that npm version stamps both package.json and the lockfile.

Once merged, cut 1.1.1 again by drafting a release with tag 1.1.1 targeting main.

🤖 Generated with Claude Code

This PR was posted by AI on Joe's behalf.