Proposal: make `main` the nightly-vetted branch, and gate promotion on a full physics run

Summary

Right now develop is the GitHub default branch, so anyone who clones GPEC gets the
integration branch. Since the package is not registered and the docs install it by
git clone + Pkg.instantiate (docs/src/set_up.md:66), the default branch is our
distribution channel — we are shipping unvetted code to new users by default.

This proposes a three-tier verification model and a redefinition of main:

• develop — integration branch. Everything merges here, as today.
• main — blessed: fast-forward only, and only to develop commits that passed the
  full front-to-back regression suite. Becomes the GitHub default branch — what users clone
  and install.
• Version tags on main — cut intermittently, when maintainers are happy, for citation
  and reproducibility.

The verification suite behind it is the golden-value regression overhaul now underway (converged
physics pins on δW, Δ′, perturbed-equilibrium quantities, tearing γ, NTV torque, across
equilibrium scans), which also fixes the harness confounds in #338.

The three tiers

Tier	Trigger	Where	Contents
1 — fast	every PR push	GitHub Actions	unit tests + fast analytic golden cases
2 — selective	maintainer label, when ready to merge into develop	feynman cluster	golden cases selected by what the diff touches
3 — full	every push to develop, nightly as backstop	feynman cluster	every golden case; a green result is what makes a commit promotable

Tier 2 exists so that contributors are not made to run the whole suite for a change confined to
one module: a change to the Δ′ calculation need not re-run the kinetic or perturbed-equilibrium
cases, while a change to spline gridding re-runs everything. The selection map fails open
(anything unmapped selects the full tier), and because tier 3 runs on every develop push, the
map validates itself: any case that fails at tier 3 but would have been skipped at tier 2 is a
map bug we can detect and fix automatically.

Tier 3 runs per-push rather than only nightly because attribution is otherwise expensive — if
five PRs land in a day and a nightly goes red, someone owes a bisect at full-suite cost. The
cluster has 50 SLURM CPUs and harness cases are independent processes, so per-push is minutes
of wall time.

Why main should be verification, not releases

Three concerns are usually conflated in one branch:

1. Integration — where work lands. Continuous. Needs a branch (develop).
2. Verification — "this commit passed the full physics suite." Continuous, mechanical,
   automatic. Needs a branch (main).
3. Release — "maintainers judge this fit to cite and depend on." Discrete, human, semver.
   Needs a tag, not a branch.

For a scientific code whose users clone the repo, verification is the property they need
continuously; releases are for papers and reproducibility. So: main moves whenever the full
suite is green, and tags mark the points humans bless.

Alternatives considered

A separate stable branch (vetted) plus main (versioned releases). stable and main
would differ only by whether a version had been cut at that commit — which is exactly what a tag
encodes. The extra long-lived branch adds a second merge path, a drift risk between two branches
that must stay related, and ambiguity about which branch a hotfix targets, in exchange for a
convenience that git checkout v0.3.1 already provides.

Versioning every merge into main. This collides with fast-forward-only promotion: if main
only fast-forwards, no commit can originate there, so a version bump must land on develop and
flow through. Versioning every merge would put a Project.toml bump in every PR. Version bumps
should be deliberate and occasional; verification is the thing that should be continuous.

Backporting (fixing an old release while develop moves on) is the one case that would
justify more branches. It is served by release/0.2.x branches cut on demand, which is
orthogonal to this proposal and can be added later. Do we foresee needing it?

What this requires

1. Fast-forward-only promotion to main. main advances to the exact SHA that tier 3
   tested — never to develop's tip at promotion time, and never via a merge commit, which
   would publish a tree nothing tested. Requires enabling required_linear_history on main.
2. Promotion opens a PR; a human merges it. Keeps main's existing 2-approval rule and our
   human-review policy intact. (Tradeoff: a bot-opened fast-forward PR still needing two
   approvals may bottleneck promotion. The alternative — letting automation push to the
   public-install branch — seems worse. Opinions welcome.)
3. Change the default branch to main once it exists in blessed form, and update the clone
   instructions in docs/src/set_up.md.
4. Revise the hotfix workflow. Today hotfix/ branches from main and merges into main +
   develop (docs/development/git-workflow.md). That puts a commit on main that is not an
   ancestor of develop, which breaks fast-forward promotion permanently. Revised: branch from
   the blessed SHA, PR into develop, expedited full-tier run, then normal promotion. A genuine
   emergency uses an explicit promote:unblessed label with recorded justification, so an
   override is visible rather than silent.
5. Make a frozen main loud. A red tier 3 stops promotion by design. That needs an
   auto-opened issue and a "days since main advanced" signal, or a freeze quietly becomes the
   status quo. Two documented unblock paths: fix the regression, or — if the change was an
   intended physics improvement — regenerate the golden values with convergence evidence.
6. Contributor-facing rule: a PR that intentionally changes physics regenerates its golden
   values in that PR. Otherwise it passes tier 1, turns develop red at tier 3, and freezes
   promotion for everyone else.

Unrelated bug found while checking this

develop's branch protection requires the contexts runtests 1.11 - ubuntu-latest and
runtests 1.x - ubuntu-latest. But test.yaml is path-filtered and deliberately publishes a
stable Tests job so that a skipped suite does not block a merge — the workflow says so in a
comment. As configured, a PR that touches no Julia code skips the matrix jobs, their contexts
never report, and the required check stays pending indefinitely. It has not bitten us because
almost every PR touches Julia. Protection should point at Tests instead. Worth fixing before
we add tier checks, or the new tiers inherit the same trap.

Questions for the group

• Does main-as-blessed vs a separate stable branch match how people expect to consume GPEC?
• Two approvals on an automated fast-forward promotion PR: right, or a bottleneck?
• Do we anticipate backporting fixes to older releases?
• Who owns the feynman-side runner, and do we want a self-hosted GitHub Actions runner there
  (integrated status checks, but the repo is public, so fork PRs are a code-execution risk and
  the workflow would have to be restricted to schedule/workflow_dispatch with an ephemeral
  runner) or a cron + sbatch job reporting through the API (safer, less integrated)?