Book an event on a single calendar with a booking code

Input for POST /public/booking/calendar-events/.

Mirrors CreateEventWithCodeInput (GraphQL) minus its code field -- the booking code travels as the X-Booking-Code header instead (see calendar_integration.booking_auth). calendar_id is never accepted here: it comes strictly from the resolved token, never from client input.

CalendarEventSerializer plus the self-service management object.

Used ONLY to render the 201 response of a booking-code create or reschedule viewset (BookingCodeCalendarEventViewSet, BookingCodeAppointmentTypeEventViewSet, BookingCodeRescheduleEventViewSet, BookingCodeRescheduleAppointmentTypeEventViewSet) -- never for a read, and never for get_optimized_queryset: management is not a model field or relation, it does not exist on CalendarEventVirtualModel, and django-virtual-models' LookupFinder would raise MissingVirtualModelFieldException if this subclass were ever handed to get_optimized_queryset (it walks every readable field looking for a matching virtual-model entry). Callers therefore build the optimized queryset with the PLAIN CalendarEventSerializer first, and only use this subclass afterwards, purely to render .data on the already- fetched instance.

The view sets event.management (a plain object carrying reschedule_code / cancel_code, matching BookingManagementCodesSerializer's two fields) on the event instance before calling this serializer -- there is nothing in the database for this field to read, to_representation finds it via a plain getattr(instance, "management"), same as any other declared field.