docs(blueprint-platform): record restaurant demo validation

docs/consumption/restaurant-demo-flow-validation.md

@@ -0,0 +1,51 @@
+# Restaurant Demo Flow Validation
+
+## Scope
+
+This document records the Stage 48 validation pass for the deployed restaurant demo hosted behind the public `dream-views.com` demo domains.
+
+## Validated On
+
+- Date: `2026-03-31`
+- Auth entrypoint: `https://auth.dream-views.com`
+- Demo hosts:
+  - `https://waiter-floor-demo.dream-views.com`
+  - `https://customer-orders-demo.dream-views.com`
+  - `https://kitchen-ops-demo.dream-views.com`
+  - `https://pos-transactions-demo.dream-views.com`
+
+## Confirmed Working
+
+- Public Thalos session login and cookie-backed session validation work through the public host path.
+- The four restaurant web apps serve the updated lifecycle-oriented SPA bundles.
+- Public routes for waiter, customer, kitchen, and POS demos return `200`.
+- UI copy now describes the intended restaurant flow:
+  - order accepted
+  - kitchen preparation
+  - ready for handoff
+  - served and payable
+  - payment captured
+
+## Important Runtime Note
+
+- Session cookies are scoped to the public `dream-views.com` hosts.
+- Validation against `127.0.0.1` BFF ports will not accurately exercise the deployed session behavior because those cookies do not round-trip on localhost.
+- End-to-end validation for the deployed demo should use the public auth host plus the public demo hosts.
+
+## Current Limitation
+
+The deployed demo still does not fully propagate a newly submitted order through the shared restaurant lifecycle:
+
+- `POST /api/customer/orders` accepts a new order and returns success.
+- The same order is not yet visible in customer detail queries.
+- The order does not appear on the kitchen board.
+- Waiter activity does not reflect the new order.
+- POS summary does not expose that order as newly payable.
+
+This means the public SPAs now describe a connected flow more clearly, but the runtime still contains static or partially projected demo read models that do not fully reflect live mutations.
+
+## Recommended Follow-Up
+
+- Replace remaining static demo projections in restaurant read paths with lifecycle-backed projections sourced from the shared operations and kitchen stores.
+- Re-run Stage 48 validation after that propagation work lands.
+- Keep the seeded PostgreSQL data as deterministic walkthrough material, not as proof of the runtime mutation path.