Booking write path (the core flow)

1. POST /v1/bookings → Throttler → JwtAuthGuard → RolesGuard → TenantGuard (binds org_id into CLS).
2. One DB transaction: insert the booking. The EXCLUDE constraint atomically rejects overlaps → mapped to 409 booking_conflict.
3. Workflow rules evaluate → status confirmed or pending_approval (+ approval steps).
4. In the same tx, a notification row is written to outbox (dual-write solved).
5. Commit → SSE publishes booking.created; the audit interceptor records the change.
6. The worker later drains the outbox and sends via Resend (retry → DLQ on failure).

Why this shape

• No double-booking is a database guarantee (exclusion constraint), not an app check — race-proof across every code path.
• Tenant isolation is enforced once, in ScopedRepository; cross-tenant reads return NOT_FOUND, never leak existence.
• Dual-write (email / outbound webhooks) goes through a transactional outbox + worker — never a synchronous send in the request path.
• Inbound webhooks verify the Svix signature on the raw body before any read, then dedupe on an idempotency ledger.
• Realtime uses SSE (one-way push) — sufficient at <1k concurrent; a WebSocket upgrade path is documented.