orders cutover now gated behind parity harness

Checkout has run on two independent stacks — Rails 3.2 orders-api and the new Encore.ts orders service — since early July, but until this change shipped, cutover for any given traffic slice was still a judgment call. As of #241, it isn't anymore: nothing promotes to production traffic until Harness reports a full week of 99.999% parity on that slice. No manual override, no exception process.

Why: checkout is the highest-blast-radius surface in the whole migration. A subtle rounding bug or a dropped field here costs real money and real trust, and it would be easy under deadline pressure to wave through a slice that looks "close enough." Making the gate a database rule instead of a policy removes that temptation entirely — there's no button anyone can press to skip it.

What it means for you: if you're on a fleet whose service touches checkout, your traffic doesn't cut over until the numbers say so, full stop. If you're not on orders, the practical effect is that Harness's orders dashboard becomes the thing to watch for the next several weeks — the parity percentage there is now load-bearing, not just informational.

The gate currently reads 99.987%, climbing. The remaining gap traces mostly to the refund-rounding question working through Q&A right now (see the orders-shadow-traffic news post) — once that resolves, expect the number to move quickly toward the 99.999% threshold.