implement the octo availability-check endpoint and booking status lifecycle

Steps

1. call the Availability Calendar endpoint (POST /availability/calendar) for a date range to populate a calendar view; it returns one object per localDate with status (AVAILABLE, FREESALE, SOLD_OUT, LIMITED, CLOSED), vacancies, and capacity, but does not itself yield a bookable ID
2. once a date/time is selected, call the Availability Check endpoint (POST /availability) passing one of localDate, or localDateStart+localDateEnd, or availabilityIds; this returns per-departure Availability objects each with a unique id (the availabilityId) and utcCutoffAt — this id is required to create a booking
3. create a booking reservation via POST /bookings with productId, optionId, availabilityId, and unitItems; implementations (e.g. Ventrata's) create the booking with status ON_HOLD while payment and customer details are collected
4. confirm the booking with POST /bookings/{uuid}/confirm to finalize it; use PATCH /bookings/{uuid} to modify an unconfirmed booking, or POST /bookings/{uuid}/extend to prolong the hold before it expires
5. cancel a booking with POST /bookings/{uuid}/cancel (the OCTO spec's changelog notes this replaced an earlier DELETE /bookings/{uuid} design) — cancellation is only permitted when the booking is within its cancellation cut-off window
6. send the required Octo-Capabilities request header (listing which optional capability IDs, e.g. pricing, are being requested) on every call, and check the returned Octo-Capabilities response header to confirm what the server actually honored