Resume an interrupted checkout: return a customer to their parked workflow step instead of an empty basket

A customer who reaches the payment page then closes the tab, or navigates back to the booking page, leaves their order locked (in checkout). Today the session cart forgets any order that is not the editable basket, so on return they see an empty basket, and their own held seats block them from re-booking the same slot until the checkout times out.

This returns them to their in-progress checkout instead.

Cart. BookingCart now keeps its per-session pointer through checkout (a locked order), not only the editable basket (empty or pending), and drops it once the order is done for the session (placed, cancelled, or gone). current() still exposes only the editable basket; a new activeOrder() exposes the tracked order whatever its stage.

Resume. A request subscriber in yoyaku_calendar_interaction, CheckoutResumeRedirect, uses it: when a customer lands on the slot booking page and their session order is locked, it resolves the order running workflow instance and redirects them to its parked step (the payment page), carrying a fresh capability token, the same handoff a fresh checkout uses. This works for anonymous customers because the session already stores the order id.

Safety. The order is never unlocked here: a payment could be in flight in another tab, and the locked flag alone cannot tell. The only way out of checkout stays the workflow own Back or Cancel step, which reconciles with the gateway. The subscriber only ever acts on a locked order, so an editable basket stays on the booking page for further editing.

Covered by kernel tests: the cart keeps its order through the lock and forgets it once placed, and the subscriber redirects a locked order to its step with a valid token while leaving a pending basket and other routes untouched.