deploy: the staging branch is 166 commits behind main, so staging validates nothing

[NathanTarbert]

Railway deploys staging from the staging branch and production from main. But:

$ git rev-list --left-right --count origin/main...origin/staging
100    0

staging is 100 commits behind main and 0 ahead. Staging is therefore running code from before the groundedness gate (#143), the one-answer-per-ticket arbitration (#172), and the schema-drift guard (#180).

Why it matters

Staging exists to rehearse what production is about to do. Right now it rehearses something production left behind weeks ago, so a staging pass proves nothing about a main deploy. It also means any PR opened against staging (see #188) sweeps 100 unrelated commits into its own diff, which makes it unreviewable.

Fix

Fast-forward staging to main, then decide the standing rule — either staging is continuously fast-forwarded from main, or release branches are cut from main into staging. Document whichever we pick in docs/deployment.md so it does not silently drift again.

[NathanTarbert]

Re-measured today, since the number in the title has moved a long way.

$ git rev-list --count origin/staging..origin/main
166
$ git rev-list --count origin/main..origin/staging
0

Staging's tip is 8a6b2c8 from 2026-07-24 ("Merge pull request #133 from CopilotKit/docs/staging-deploy-model"). main is at 0cc9dc7 from 2026-09-08. So it's 166 behind and 0 ahead — 47 days, and nothing on staging that isn't on main, which means a fast-forward is all this needs rather than a merge.

Retitled from 100 to 166 so the number matches what's measurable. Worth noting the count will keep drifting while this sits, so the fix is the forward-only rule rather than a one-off catch-up.