Issue #3613574: Bulk delete redirects to the global slots page: the confirm form re-reads the tempstore after deleting it

Change

• BulkDeleteConfirmForm::selection() reads the hand-off once per request and keeps it. submitForm() deletes the tempstore entry so a reload cannot delete twice, and then still needs the return route: re-reading the store at that point found it gone and fell back to entity.yoyaku_slot.collection, so a delete started anywhere else landed on the global slot list. Both the batch branch and the "nothing to delete" branch were affected, and all three surfaces that hand off a delete (the bookings tab, the slot overview, the booking overview) store a return route, so all three were landing on the wrong page.
• BookingsForm no longer reads the transaction map with a NULL key. A booking need not belong to a transaction (an operator-created hold has none), and $transactions[NULL] raised "Using null as an array offset is deprecated", which a later PHP will make an error. Found while writing the test below.

Not a third instance: BulkSlotUpdateForm also redirects to the global slot collection, but bulk_slots is only ever handed off by that same global list, so its redirect is correct and it is left alone.

Testing

New BookingsTabTest::testBulkDeleteReturnsToTheTab(): deletes a booking from a resource-scoped bookings tab and asserts the landing page is that tab. On the unfixed code it fails with "Current page is /admin/booking/slot, but /admin/booking/resource/1/bookings expected", which is the reported symptom; it also fails earlier on the NULL-key deprecation, since a hold with no order is exactly the case that triggers it.

Green: yoyaku_ui functional suite (11 tests, 139 assertions) and yoyaku_ui kernel (8 tests) in Docker and on the host respectively. phpcs clean at --warning-severity=1. The 6 deprecations in the functional runs come from contrib modules on the test site (crop, devel), not from this change.