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

Problem/Motivation

Deleting bookings from a resource's Bookings tab returns to the global slots page instead of the tab the operator was on. The same happens from any surface that hands off to the bulk-delete confirmation.

BookingsForm stores the return route before redirecting: 'return' => $this->getRouteMatch()->getRouteName() with its raw parameters, in the yoyaku_ui tempstore under bulk_delete. BulkDeleteConfirmForm::getCancelUrl() reads that and falls back to entity.yoyaku_slot.collection when it is empty.

The fallback always wins on submit, because submitForm() deletes the tempstore entry before the redirect is computed: it reads the selection, then deletes the entry so the batch cannot run twice, then calls setRedirectUrl($this->getCancelUrl()), and getCancelUrl() calls selection() again. selection() reads the tempstore fresh every time and is not memoized, so by then it returns the empty defaults.

The return route is therefore lost between the two reads, and every bulk delete ends on the global slots list.

Proposed resolution

Compute the redirect from the selection already in hand, before the tempstore entry is deleted, rather than re-reading it. Memoizing selection() also works and keeps getCancelUrl() honest for the confirmation page itself, which reads it before the deletion.

Check the sibling bulk forms for the same shape: the slot bulk update hands off through the same tempstore.

Remaining tasks

• Fix the redirect, and the "nothing to delete" branch which computes it the same way.
• Audit the sibling bulk forms.
• Functional coverage: delete from a resource tab and assert the landing page is that tab, which is what would have caught this.

User interface changes

After a bulk delete the operator returns to the page they started from.

API changes

None.