ci(release): drop the stable approval gate and run nightlies once a day

[thymikee]

Summary

Every release run spent seconds deciding and minutes queued: Plan executes in ~12s, while recent schedule runs waited 30s–31min for an ubuntu-latest runner. Seven of the eight daily cron runs only reported "shipped today".

• No stable approval. The v* tag ruleset (creation/update/deletion, org-admin bypass only) already gates stable releases, and Plan still refuses to publish if that ruleset or the npm-publish branch policy weakens. The release environment approval was a second click by the same admin. Drops the approve job and the reviewer check.
• Fixes Tag nightly, which never ran: a skipped approve skipped every job downstream of publish on nightlies, so no nightly/* tag exists.
• Nightly once a day (23 1 * * *). Plan waits up to 20 minutes for main's HEAD CI, as tags already did; failed, cancelled, or still-running CI skips that day. Run Release on main to publish one by hand. Removes the same-day npm lookup.
• Every main commit gets its own CI run. ci.yml keyed its concurrency group by ref, so each main push cancelled the previous commit's run; v0.21.28's Plan failed when the next merge cancelled CI on its tag. Main runs are now grouped by SHA; pull requests still cancel superseded runs. Costs more runner time on busy days.

Docs: CONTRIBUTING.md release channels and one-time setup. 6 files.

Keep the release environment until v0.21.28 ships: its tag predates this change, so any retry on it still runs the approval job. Delete the environment afterwards.

Validation

At e60e96f and 8ba6f31: pnpm check:affected --run passed; scripts/__tests__/release-plan.test.ts and test/ci/release-workflow.test.ts pass (13 tests). A fresh-context review found the skip wording too narrow (fixed) and a dead test input (fixed). The PR's own Release dry run exercises the workflow.

🤖 Generated with Claude Code

[cubic-dev-ai]

All reported issues were addressed across 5 files

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[github-actions]

Size Report

Metric	Base	Current	Diff
Installed (including dependencies)	5.24 MB	5.24 MB	0 B
Package (unpacked)	5.24 MB	5.24 MB	0 B
Package (download)	1.58 MB	1.58 MB	+9 B

Startup median (7 runs, lower is better):

Scenario	Base	Current	Diff
CLI --version	29.1 ms	28.9 ms	-0.2 ms
CLI --help	82.6 ms	81.5 ms	-1.1 ms

[thymikee]

This PR is ready at 5c7bc7c. The change reads correctly: the publish chain now runs on a plain success, which is what the "Tag nightly never ran" fix needs. All 29 checks pass, and the PR's own Release dry run covers the Plan and Build routes. The publish, tag-nightly and stable paths cannot run in a PR, so CI does not exercise them, and the tag-nightly fix can only be confirmed by the first scheduled run after merge. I also could not read the live GitHub settings (release environment, tag ruleset, npm-publish policy), so the "ruleset is already admin-only" claim rests on Plan's runtime check.

Not blocking, and you can take or leave these: the deleted approve-gate test has no replacement, so a new test in test/ci/release-workflow.test.ts could assert that publish.needs equals ['plan','build'] and that its if only tests plan.outputs.mode (otherwise a conditionally skipped ancestor would silently skip tag-nightly again); the nightly bullet in CONTRIBUTING.md is one long line and could be rewrapped, with a note that a dispatch on main now waits up to 20 minutes for in-progress CI; and the ci.yml concurrency change is not exercised by the Release dry run because the release.yml paths filter excludes ci.yml, so it could land separately or the PR could say the next main merge validates it.

On the open threads, the cubic-dev-ai P2 on a duplicate nightly after a failed tag-nightly does not apply, so you can resolve it: the run number is in the version string, so it is never republished, and the next scheduled run is the next UTC day. #3621 (comment)

Before merge, nothing else is needed. Keep the release environment until v0.21.28 ships, then delete it.