Keep prerelease CLI tags out of GitHub’s stable latest channel

[rmcdaniel]

Problem

The published 2.0.0-rc.13 GitHub Release is marked as a non-prerelease even though the tag is a SemVer release candidate; 2.0.0-rc.12 and 2.0.0-rc.11 are marked as prereleases. The CLI installer and upgrade catalog also resolve GitHub’s stable-only /releases/latest channel by default. That couples current-version discovery to incorrect release metadata: a correctly classified RC can disappear from the default CLI channel, while an incorrectly classified RC is presented as the stable Latest release. This weakens the explicit stable-release boundary before 2.0.0 is authorized.

Acceptance criteria

• CLI release publication derives GitHub prerelease metadata from the validated SemVer tag: alpha, beta, and RC tags are published with prerelease: true.
• A stable 2.0.0 GitHub Release can be published with prerelease: false only after the existing explicit stable-release authorization.
• Default install and dw upgrade discovery resolve the supported CLI prerelease channel explicitly instead of requiring an RC to occupy GitHub’s stable-only Latest channel.
• Correct the public 2.0.0-rc.13 release metadata without replacing its tag or immutable assets.
• Release verification checks the public GitHub API metadata and default install/upgrade resolution for both prerelease and stable-transition cases.
• Regression coverage fails when a prerelease tag is exposed as a stable GitHub Release or when the supported prerelease becomes undiscoverable.

Delete when

Delete when public prerelease metadata, install/upgrade discovery, and the stable authorization boundary are aligned and verified for a real successor release.