Unlock the order from the payment step's own timeout instead of a separate workflow node

Problem/Motivation

The example booking workflow's diagram shows an Unlock the order step with no lock step anywhere to match it. The lock is taken inside the payment step, as the payer is handed off to the provider: OrderLockSubscriber brackets that round-trip, locking on the handoff and unlocking on any outcome that took no money. So unlocking is already the step's own work, and the node on the outgoing edge is half of that bracket leaked onto the diagram, put there because a step had no way to react to its own timeout.

The step also listens for an outcome nothing announces. PaymentWorkflowBridge resumes a lapsed checkout with expired, but the step's outgoing flows route on timeout, which only the node's own resume timeout action produces. A checkout that lapses the ordinary way, through the reaper, therefore resumes the step with an outcome no flow matches, and orchestra reports that as a dead end and halts the branch. The backstop timeout is the only road that routes, which is why the unlock node looks like it is carrying the step.

Proposed resolution

Add a timeout action to yoyaku_orchestra, beside the one that ends a lapsed basket, which unlocks the order and resumes the step with expired. Point the payment step's timeout at it, route the step's lapse edge on expired rather than timeout, and delete the Unlock the order node. The bracket closes where it opens, and a lapsed checkout leaves the run in the same place through the same edge whichever road closed it.

The action deliberately does not touch the payment. There is no provider-side way to end a checkout the payer never answered: the gateway can only be asked what happened, and its cancel operation reverses an authorization that exists rather than abandoning a pending session. Writing the payment off locally would be a claim that no money moved, which is exactly what the reaper refuses to make without asking. So the payment stays pending and stays the reaper's, and LockedCheckoutHooks already covers an order whose payment later leaves pending without resolving it.

Remaining tasks

• The timeout action, and the example workflow changes that retire the node.
• Tests: a checkout lapsing by either road leaves the run at the registration form with an editable basket, and a step whose payer never asked to pay is not left parked for ever.
• Documentation and the French translation.