ci(release): promote the latest nightly with versions and notes that need no bumps - #487

Promoting a nightly to stable needed three manual steps: typing the nightly tag, bumping styal-version.json after every release (otherwise the next promotion fails because the tag exists, and later nightlies sort below the stable they follow), and writing release notes, since the stable release body was a single "promoted from" line.

• Fork Release makes source_tag optional. Without it, the workflow promotes the newest published nightly and posts a notice naming the tag and commit. The stable version comes from the nightly's tag, so v0.1.1-nightly.* ships as 0.1.1. This follows upstream's stable promotion (001f06d543, feat(ci): ship stable releases from the latest nightly commit pingdotgg/t3code#10410 upstream), adapted to the fork's separate release workflow.
• Nightlies build the next unreleased version. styal-version.json names it until a stable release reaches it; after that, resolve-nightly-release.ts takes the newest stable tag and uses its next patch. The file only changes for a minor or major bump.
• Stable release notes list the fork and upstream changes since the previous stable release, using the nightly's "What's Changed" generator, now shared as render_release_notes in .github/scripts/release-changelog.sh. The first stable release has no previous stable to compare against and keeps the short placeholder, to be replaced by hand after publishing.
• The nightly and stable publish jobs load .github/scripts from the workflow's own commit in a sparse release-tools checkout. The source they release is an earlier commit (for stable, always an earlier nightly) that can predate the helpers. The nightly version step skips the stable-tag lookup on a candidate that predates it.

Validation

• resolve-nightly-release.test.ts covers keeping the declared version until a stable reaches it, the next patch after a released version, a deliberate minor bump winning over that patch, and rejecting a non-plain stable tag.
• release-changelog.test.ts covers latest_stable_tag choosing by version (v0.10.1 over v0.9.0), ignoring nightly and -rc tags, resolving the tag before a given one, and returning nothing before the first stable release.
• render_release_notes run against this repository for v0.1.0-nightly.20260925.419 to v0.1.0-nightly.20260926.420 reproduces the published nightly 420 notes exactly.
• The nightly version step's shell produces 0.1.0-nightly.* with no stable tag and 0.1.1-nightly.* after v0.1.0, and skips the lookup on candidates that predate the helper.
• The default-nightly lookup, run against the fork's releases, picks the newest nightly and ignores preview releases; the tag-to-version parsing gives 0.1.0 for v0.1.0-nightly.20260926.420.
• The fork remote has no plain vX.Y.Z tags, so the first stable release resolves no previous stable.
• A dry run of this branch's Fork Release with no source_tag promoted v0.1.0-nightly.20260926.421 to v0.1.0, built and verified every desktop and CLI artifact, loaded the release scripts from the workflow commit, and rendered the first-release placeholder notes. Tag creation and publishing are skipped in a dry run.

Written by an agent (Claude Code, claude-opus-5-5).