Booking Engine (PL-T186)

Every mutation flows through the booking engine. On create, the engine acquires a per-(tenant, location) asyncio lock, validates against opening hours (via the effective-hours resolver), maintenance blocks (via the expansion service), buffer rules, and resource capacity, then writes the Booking document with status RESERVED. Idempotency keys passed by the client cause repeated submits to return the same booking rather than duplicating — critical for flaky mobile networks during checkout.

Multi-resource bookings (e.g. "three adjacent lanes for a corporate event") are stored as a single Booking with a list[resource_ids], so the reservation is atomic — no half-booked groups. Conflict responses don't dead-end the customer: the engine returns suggested_slots from a ±2 h scan around the requested time plus a can_join_waitlist boolean, and the front-end renders alternatives with one-tap selection. Status transitions (RESERVED → CONFIRMED → CHECKED_IN → COMPLETED, or any path to CANCELLED / NO_SHOW) are recorded in an audit_trail array on the document — actor, action, timestamp, optional metadata.

No-show logic runs on a grace period from ChainVenueProfile (e.g. 15 minutes after start time, the booking auto-flips to NO_SHOW unless an operator checks it in). Every status change broadcasts on an SSE channel chain.bookings.{tenant}.{location}, so the calendar, floorplan, and operator console all refresh within a few hundred milliseconds without polling.