Booking: resources, availability and slots, with overlaps refused inside the write

Arnel, 14 September 2026: online booking is one of the systems a barako expert should brew. #814 covers events and registrations, #580 a reservation under a floor, #838 payments. Nothing models when something can be booked: a room, a doctor, a vehicle or a class slot.

## Change

- **Resources and availability.** A resource (any entry, by reference) has weekly opening hours in the tenant's time zone, exceptions (holidays, closures) and a slot length or free-form duration.
- **Bookings** are entries referencing a resource with a start and end, refused inside the write when they overlap another active booking of the same resource (the same in-transaction guarantee as #830 and #808).
- **Holds.** A pending booking holds the slot for a set time while payment completes (#838), then frees it (#580).
- **Public availability.** `GET /api/public/availability?resource=&from=&to=` returns free slots, never who booked them, throttled.
- **Calendar files.** An `.ics` for a booking, and a feed per resource for staff (signed URL).

## Done when

- Two concurrent requests for the same slot produce one booking; a held slot frees itself after its hold expires; public availability never reveals booking details.

## Where it lives

Module: `BarakoCMS.Booking`, owning resources, availability and the public availability endpoint. The overlap refusal is the module's lifecycle hook, which runs inside the write, the way the Pages module's hook does. Holds use #580 if it lands in core first.

Start with the BarakoCMS.Booking module and its lifecycle hook, then inspect the Pages module hook that runs inside the write. Trace the public availability endpoint and the existing work in #580 and #838. Done means concurrent same-slot writes yield one booking, expired holds free the slot, and availability exposes no booking details.

Written by the indexing model from the issue text.