ci(nightly): accept a pre-resolved stack via source_ref

[incognitojam]

When the nightly rebase onto pingdotgg/t3code conflicts, the run fails in prepare and a maintainer resolves the stack locally — but the ruleset blocks force-pushing main from the CLI, so there was no way to get the resolved stack back onto main.

This adds an optional source_ref dispatch input. The run checks out that ref (a branch or SHA pushed to origin holding the resolved stack) instead of main, rebases it onto upstream (a no-op when nothing moved since, a loud conflict failure when it did), runs the full verification, publishes the release, and promotes it to main through the existing backup and lease mechanics. An invalid source_ref fails in a pre-checkout validation step with a readable message. Pairing source_ref with dry_run verifies a resolution without publishing or promoting anything.

The fork_ref split

Today the run always checks out main, so one commit serves every role. With source_ref there are three: M = origin/main's tip, R = the provided stack, C = the candidate after the rebase. fork_ref keeps its meaning as the stack source (R) and a new main_ref output carries M, resolved once in prepare so every later check compares against the same snapshot.

Role	Commit	Why
Checkout ref	R	The stack being rebased and verified.
FORK_SOURCE_REF in both changelog steps	R	Release notes must enumerate the stack that ships.
Backup snapshot source	M	The backup captures the commit being replaced; R already exists as the maintainer's branch.
Moved-main skip comparison	M	Compares live main against the run-start snapshot.
Lease (--force-with-lease=refs/heads/main:…)	M	Pins main's expected value.
Nothing-to-promote short-circuit	C == M	Was C == R, meaning "the rebase was a no-op". On a source_ref run C == R is the normal case and promotion still has work to do; the real question is whether main is already the candidate.

The prepare job's no-change alignment step gets the same treatment (all four of its uses are M). On scheduled runs fork_ref and main_ref are the same commit, so behaviour is unchanged.

Verified with actionlint (only the pre-existing blacksmith runner-label warning) and by extracting every run: body from both this workflow and the pre-change one and replaying them against stubbed git/gh: scheduled runs produce identical command sequences, and the source_ref paths cover promote, C == M no-op, moved main, dry_run, and invalid ref.

Model: Claude Opus 5, harness: T3 Code