docs(blueprint-platform): update restaurant runtime validation

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

@@ -2,7 +2,7 @@
 
 ## Scope
 
-This document records the Stage 48 validation pass for the deployed restaurant demo hosted behind the public `dream-views.com` demo domains.
+This document records the restaurant demo validation passes across Stage 48 and the Stage 49 propagation follow-up hosted behind the public `dream-views.com` demo domains.
 
 ## Validated On
 
@@ -17,42 +17,59 @@ This document records the Stage 48 validation pass for the deployed restaurant d
 ## 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.
+- The restaurant runtime was refreshed from current repo state, including `operations-dal`, `kitchen-dal`, `operations-service`, `kitchen-service`, `waiter-floor-bff`, `customer-orders-bff`, `kitchen-ops-bff`, and `pos-transactions-bff`.
 - 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
+- A customer-origin order now propagates through the shared lifecycle:
+  - `POST /api/customer/orders` accepts the order
+  - customer status/detail show the new order
+  - kitchen board derives a queued ticket for that order
+  - kitchen transitions move the order into a payable POS check
+  - POS capture succeeds for the payable check
+- A waiter-origin order now propagates into waiter activity and the kitchen board through the same shared lifecycle.
 
 ## 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.
+- Validation against `127.0.0.1` BFF ports does 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
+## Validation Evidence
 
-The deployed demo still does not fully propagate a newly submitted order through the shared restaurant lifecycle:
+### Customer-origin flow
 
-- `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.
+- Submitted order: `ORD-STAGE49-001`
+- Customer detail moved to `accepted`
+- Kitchen board derived ticket `KT-49001`
+- Kitchen transitions advanced the order to `served`
+- POS exposed payable check `CHK-ORD-STAGE49-001`
+- POS capture succeeded and reduced open balance to `0`
 
-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.
+### Waiter-origin flow
+
+- Submitted order: `ORD-STAGE49-WAITER-001`
+- Waiter activity reflected the new submission immediately
+- Kitchen board derived a queued ticket for the waiter-origin order
+
+## Residual Limitations
+
+The runtime is now connected, but two important limitations remain:
+
+- Customer order detail remains `served` after POS capture instead of advancing to a paid or closed order state.
+- Derived kitchen identifiers can collide across orders with similar numeric suffixes. During validation, both `ORD-STAGE49-001` and `ORD-STAGE49-WAITER-001` projected to `KT-49001`/`WK-49001` at different times.
+- Kitchen transition responses still report `transitioned: false` even though the persisted restaurant and kitchen state clearly change.
+
+These do not block the proof that the apps now work together, but they should be treated as follow-up hardening items before we present the restaurant flow as fully production-shaped.
+
+## Stage Status
+
+- Stage 48 blocked finding is partially resolved.
+- The core propagation gap is closed: new orders now move across customer or waiter entrypoints into kitchen visibility and POS payable state.
+- Stage 49 runtime rollout can be considered complete.
+- Final demo validation should remain tracked until the residual limitations above are either fixed or explicitly accepted.
 
 ## Recommended Follow-Up
 
-The blocked Stage 48 finding now rolls into Stage 49:
-
-- `plan/2026-03-31-s49-master-restaurant-propagation-and-runtime-alignment.md`
-- `docs/architecture/stage49-52-restaurant-propagation-guardrails.md`
-
-Execution focus:
-
-- replace remaining static or summary-only restaurant read projections with lifecycle-backed projections sourced from the shared operations and kitchen stores
-- redeploy aligned restaurant runtime images before re-validating the public demo
-- keep the seeded PostgreSQL data as deterministic walkthrough material, not as proof of the runtime mutation path
+- add a payment-to-order closure projection so paid checks can move customer-facing order state beyond `served`
+- replace the current derived kitchen ticket/work-item identifier scheme with collision-safe IDs
+- correct kitchen transition response semantics so `transitioned` reflects successful state mutations
+- execute the reseed task only if we want the VPS database reset to a fresh deterministic walkthrough baseline