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

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.

Start by checking the branch relationship with git rev-list --left-right --count origin/main...origin/staging and review the PR against staging mentioned as #188. Fast-forward staging to main, then confirm the chosen ongoing branch rule with maintainers. Document that rule in docs/deployment.md so future staging deploys do not drift.