docs: record booking scale-up verification

PROJECT_STATE.md

@@ -2239,3 +2239,21 @@ evidence yet."
   queue is capped at six with a direct continuation link. A cached pre-roadmap CSS asset
   was found in one browser session still hiding `.page-actions`; the final live asset
   hash explicitly keeps the mobile status/action row visible.
+
+## Booking list scale-up follow-up (2026-08-10)
+
+- **Improvement found and completed**: Bookings was the last operations list that fetched
+  and searched every booking in the browser. It now uses the same bounded server-side
+  query contract as Vehicles, Data Quality and Audit: optional `query`, `page` and
+  `page_size <= 25`, with a total and total-page count. Unpaged API calls retain their
+  original list response for existing consumers.
+- **Usability**: booking search, status and page are URL-backed (`q`, `status`, `page`),
+  so an operator can reload, share or navigate back to an exact queue view.
+- **Evidence**: local web build, ruff and mypy passed. On Unraid the isolated demo-contract
+  suite passed **193 tests**; ruff and mypy passed. Live at 1440px, 254 bookings render as
+  25 rows over 11 pages, and `?q=BK-DEMO&page=1` returns four records with the filter
+  visibly retained. The synthetic demo seed was reset after the test run (2 users, 180
+  customers, 50 vehicles, 254 bookings, 33 quality issues and 20 workflow runs).
+- **Deployment**: committed and pushed as `0ef4a6fa98e6e4b4f73b0bcaa2581ecc82fbbc51`
+  (`UX: paginate booking operations`), deployed to Unraid; `.deploy/source-revision`
+  matches that commit.