ci(nightly): promote verified rebased stack to main daily

[incognitojam]

Problem

Fork Nightly rebases the patch stack onto upstream, fully verifies it (check, typecheck, desktop builds, tests), and promotes it to nightly — but origin/main was never moved by automation. It only advanced when a maintainer rebased it manually, so fresh checkouts of main lagged upstream by days.

Fix

On green nightlies, promote the verified rebased stack to main, gated to once daily:

• Once-daily gate. The prepare job computes a promote_main output: true only for the first scheduled run of the day (08:xx UTC of the five daily crons) or a workflow_dispatch with the new promote_main boolean input. Never true when dry_run is set.
• Backup ref. Before promoting, the run's starting main commit is pushed to backup/main-YYYYMMDD (plain force, so a same-day re-run doesn't fail on the existing backup).
• Leased force-push. git push --force-with-lease=refs/heads/main:${FORK_REF} origin <verified-sha>:refs/heads/main pins the lease to the exact commit the run started from. The workflow concurrency group already serializes nightly runs, so a failed lease means a human pushed main mid-run — the step fails loudly and the existing Discord failure notification fires instead of overwriting their work.
• No-change days still promote. The release job only runs when the candidate differs from origin/nightly, so on a quiet overnight the promotion step there would never fire and main could stay stale indefinitely. When the gate is on but there are no new changes, the prepare job instead aligns main to the existing origin/nightly commit — its tree is identical to the freshly rebased candidate (that is exactly what the no-change check means) and it already shipped through a fully verified release, so no re-verification is needed. The step is a clean no-op when origin/nightly doesn't exist or main already matches it, avoiding daily backup/push churn across long quiet stretches; otherwise it uses the same backup-ref and leased-force-push mechanics as the release-job step.
• Conflict path unchanged and human-owned. A rebase conflict still fails prepare before anything is promoted; maintainers resolve, verify, push a backup branch, and force-push main as before. With new changes, promotion only runs after the release publishes, and dry runs promote nothing.

Docs: added a "Keeping main current" section to docs/operations/fork-nightly.md distinguishing automated mechanical promotion (post-release, or prepare-time alignment to the released nightly on no-change days) from maintainer-reviewed conflict rebases.

Why this supersedes the merge-candidate proposal

Issue #63 proposed building candidates by merging upstream into the fork head so the workflow never owns rebase semantics. Since then the operational reality settled the boundary differently: the nightly already produces a fully verified rebased stack every run, and the only missing piece was letting main benefit from it. Promoting the verified rebase (with a backup ref and a lease guarding manual pushes) keeps main a clean patch stack — no merge commits to unwind at the next manual rebase — while conflicted rebases remain exactly the maintainer-reviewed operation they are today. The merge-candidate machinery would add a second candidate topology without removing any human responsibility.

Closes #63

---

Built by Fable 5 (claude-fable-5) on Claude Code.