Cut releases from CI and publish the ghcup channel from a branch

[hsyl20]

Set up how releases are made. Nothing has been released yet; the repo has no tags.

A release is cut from Actions -> CI -> Run workflow with release_version set to the version to release and publish ticked. CI builds and tests every platform and only then tags the revision, publishes the bindists as a GitHub Release and updates the ghcup channel. Leaving publish off rehearses all of it without tagging or publishing anything.

Tags are produced by CI, never consumed by it, so a v* tag only ever exists for a revision that built and passed everywhere, and an abandoned attempt leaves nothing behind but a red run. The v* push trigger is dropped accordingly.

• plinth-build.sh: add RELEASE_VERSION, which rewrites configure.ac's base version to the full four-component version and passes RELEASE=YES to configure, so the compiler reports exactly the released version instead of .. See Note [Release versioning]. The counter lives in the release request rather than in configure.ac: a committed four-component base would make every later snapshot build five components (9.6.166.1.20260803), one more than the tools accept. The value handed to configure is always spelled out, so this script's own RELEASE (release flavour) can never be mistaken for configure's RELEASE (version stamping). The build aborts if the compiler it produced does not report the requested version.
• ci.yml: add the release-precheck job, which rejects an empty version, a version that does not extend configure.ac, or one already released -- in seconds, rather than after a full matrix build. Verify every bindist tarball is named for the released version before generating the channel.
• ci.yml: gate the release job on the plinth-test-* suites as well as the ghcup install tests. It depended only on the latter, so a release could have shipped a compiler whose test suite had failed.
• ci.yml: publish the ghcup channel to a dedicated orphan ghcup-channel branch rather than to gh-pages, served from raw.githubusercontent.com (where ghcup fetches its own metadata too). Publishing is then a plain git push, with no build or deploy step behind it, and the branch is CI's alone, so a release cannot conflict with anything else being pushed. The branch is created on the first release, so there is nothing to set up by hand.
• configure.ac: document that the version here stays at three components.
• README.md: the new channel URL, the RELEASE_VERSION knob, and how to cut a release.