Feature: Multi-counter ordering flow (create here, pay there) #361

Feature: Multi-counter ordering flow (create here, pay there)

Summary

Support the workflow where Counter A creates an order and sends it to a payment queue, then Counter B retrieves it by ticket number/QR and completes payment. FloCafe already has durable orders, unpaid bills, idempotent order/payment work and LAN use.

Key design decision

Do not overload kitchen order.status (pending → preparing → ready → served → completed). Introduce a separate field:

checkout_stage: building | awaiting_payment | paid

Optionally a per-station kitchen dispatch setting later (on_order vs on_payment).

What already exists

• Held orders exist (main/routes/held-orders.ts) but the plan explicitly says NOT to use held-order JSON as the final implementation.
• Split checks (split_group_id, main/routes/bills.ts ~214), durable bills and idempotent payment work (fix(checkout): make split checks atomic and allocation-safe #253/fix(checkout): generate bills from a consistent order snapshot #254).

Proposed UX

COUNTER 1                 COUNTER 2
create order      →       waiting for payment
"Send to payment"          A104  $23.50, A105 $11.20 ...
Ticket A104 / QR    →     scan/click → payment

Acceptance criteria

• Order reaches awaiting_payment without kitchen seeing it (unless configured).
• A waiting-panel lists orders by ticket number and total (LAN).
• checkout_stage transitions are enforced server-side, separate from kitchen status.
• Tests for lifecycle + idempotency (mirror tests/issue-253 / issue-254).