take the release version from the tag - #53

Releasing no longer needs a version bump commit beforehand: publishing a GitHub release with the tag v<version> is enough, and the workflow commits the version back to master afterwards.

How a release works now

1. Write the changelog section ## <version>, which stays mandatory, and merge it.
2. Publish a GitHub release with the tag v<version>, marked as prerelease for versions like 3.2.0-rc.1.
3. release.yml then:
   • check: the tag has to be v + valid semver, newer than what npm has, not on JSR yet, listed in the changelog, with a matching prerelease flag. It outputs the version and the npm dist-tag.
   • test: the full test matrix.
   • publish: sets the version from the tag in the checkout (scripts/version.js) and publishes to npm with provenance.
   • jsr: publishes the same version to JSR.
   • docs: builds the documentation with that version.
   • version (new): only for regular releases (dist-tag latest). It checks out the current default branch, sets the version and commits "release " as github-actions[bot].
     • Commits merged after the tag are kept, the version commit goes on top.
     • Prereleases and fixes for older majors leave master alone.
     • Pushes with GITHUB_TOKEN don't trigger other workflows, so there's no loop. master has no branch protection, so the push goes through.

The tag points at the commit before the version commit; that can't be avoided. The published npm/JSR packages and the docs carry the right version anyway, because each job sets it before building.

Changes

• scripts/version.js (new): sets the version in package.json and keeps its copies in sync (jsr.json, src/version.ts, which is the version written into PNG metadata). The build and the npm version lifecycle script use it too.
• scripts/release-check.js: takes the version from the tag instead of requiring package.json to match it.
• jsr.yml and docs.yml: optional version input, which release.yml passes. Run by hand, they keep the version in the repository.