Issue #3619722: Retire the event sense of slot, which collides with Drupal's own event

In a Drupal codebase an event is a Symfony event, and this module dispatches plenty of them. It was calling a bookable window one as well, in the summary's own payload and in the prose around it, and TransactionSummary documented the collision itself: 'events' lists each slot as ['slot_id' => int, ...].

The wire contract moves in one piece, because a payload key alone would leave every reader behind:

• $summary['events'] is $summary['slots'] (built in TransactionSummary, defaulted in SummaryHooks and CartForm, read by PaymentSummaryHooks, the mail template and the tests);
• hook_yoyaku_summary_event_alter() is hook_yoyaku_summary_slot_alter(), and its $event parameter is $slot_summary so the BookingSlotInterface beside it keeps the name $slot;
• the theme hook yoyaku_summary_event is yoyaku_summary_slot, its template yoyaku-summary-event.html.twig is yoyaku-summary-slot.html.twig, its suggestions hook follows, and the card's CSS classes are yoyaku-summary-slot*;
• the render children under the summary are slot_N rather than event_N;
• the cart's per-card button is getSlotRemove() / removeSlot(), its element remove_slot and its #name remove-slot-N;
• TransactionSummary::getEventElement() and getEventUnit() are getSlotElement() and getSlotUnit();
• CheckinResult::$eventStart is $slotStart, and CheckinHandler::getEventStart() is getSlotStart().

The prose says slot wherever it meant the window, in src/, in every submodule, in the tests and in the docs, one line at a time rather than by substitution: per-event decision is per-slot decision, after the event has ended is after the slot has ended, an events list is a list of slots.

Four senses keep the word, deliberately. The Symfony one everywhere it already has it (BookingEvents, EventSubscriber, getSubscribedEvents(), $event, the event_dispatcher); the flood event HoldThrottle registers; the DOM events the calendar widget and the place map bind; and the reader-facing illustrations the vocabulary law already protects, such as "a bookable thing - a room, a piece of equipment, an event". Two lines in AllotmentSettings that said "two events can change the answer", meaning two writes, now say writes: in this codebase that phrasing reads as Symfony.

docs/concepts.md gains the rule beside slot-never-session, so the next sweep does not have to rediscover it: slot, never event either, with booker-facing wording named as a separate question.

No string a booker or an operator reads was touched, so no msgid moves and scripts/check-translations.php still reports every shipped string translated. These are the ones to decide on separately, and none of them is obviously wrong as it stands:

• Post-event settlement (the resource field label, and the same label in the field-rule list)
• Auto-complete after the event, Auto-mark unused after the event (a no-show)
• What the automatic sweep does to bookings still confirmed once their event has ended (plus a grace period)...
• How long after an event ends before the sweep settles a booking still confirmed...
• Booking: settle bookings after their event (the queue worker title)
• Checked in: @event (the check-in banner)
• An HTML summary of the order, grouped by event, with each ticket and its price. (the token description)
• This area is not offered as a pool for this event., This area has no capacity to offer for this event., This area is offered as a pool for this event, so it has no places to choose.
• Your places for @event are not all next to each other...
• The place grades this tariff prices... so an event can price places by viewing quality...
• ...how the hall is opened for an event is not part of it... (the venue export warning)
• ...which is how a mini-site for one event is built. (the booking-channels description)

"Post-event settlement" in particular reads better to a venue operator than any substitute would, which is why this is a wording question and not a vocabulary one.

Green locally: phpcs (the CI ruleset, exit 0), DrupalPractice, phpstan level 3, cspell over every touched file, check-translations.php, and the kernel classes that cover the payload and its readers: TransactionSummaryTest, ThemeSuggestionsTest, OrderSummaryBuilderTest, PaymentSummaryPricingTest, SummarySlotLinkTest, CartPlacesApartTest, BookingCartTest, CheckinHandlerTest, PlacesApartTest, SettleBookingsTest.