Feature: Self-service kiosk (separate /kiosk surface, restricted API boundary) #367

Feature: Self-service kiosk (separate /kiosk surface, restricted API boundary)

Summary

Add a self-service kiosk mode as a separate /kiosk surface — NOT hidden cashier controls on /pos. It reuses catalog/cart/customization logic but must not expose employee POS/admin APIs.

Security boundary (hard requirement)

A kiosk customer must not hold credentials that can call staff/product-management/refund/reporting APIs. Kiosk sessions get their own restricted token/role (or token-free limited endpoints) with review per project security conventions.

Flow (eventual)

WELCOME → DINE IN / TAKEAWAY → MENU → CUSTOMIZE → CART → COUPON / GIFT CARD → TIP → PAY → ORDER #104

First release can support Pay at counter to avoid immediate payment-terminal integration.

Dependencies (this is why kiosk is late in the roadmap)

Requires the same battle-tested services that the POS will already have: touch UI, variants (#357), add-ons, combos (#366), promotions/coupons (#359), gift cards (#363), scheduled/fulfillment semantics, tipping (#364), payment workflow. Building kiosk before those means implementing each twice.

Acceptance criteria

• /kiosk route with restricted auth boundary; employee endpoints unreachable from it.
• Catalog browse/customize/cart flows reused from the main POS stack (not reimplemented).
• "Pay at counter" first release path; full payment-terminal handoff later.