fix: #3614475 A declined payment throws the basket away, because unlocking resumes a hold the workflow, not the checkout, had taken off the clock

Closes #3614475

Two commits, one rule.

1. Put back only the clock you stopped yourself. #3614466 made a resumed hold get its own deadline back rather than a fresh window, so cancelling a payment wins no time. Right for a hold the checkout suspended, wrong for one suspended earlier: BookingWorkflowStarter takes every line off the clock when the workflow starts, so the deadline restored after a declined payment was the one from before the workflow began, already past, and the basket was swept away.

• suspendHold() goes back to simply stopping the clock, which is a handover of ownership (workflow start, place step).
• suspendHoldForCheckout() stops it and records the deadline, and only when there is a live one to take.
• resumeHold() restores only a recorded deadline, so a hold somebody else stopped stays stopped.

2. Make workflow ownership uniform. The starter suspended the lines that existed when it ran, so a line added to the basket afterwards kept a live deadline while its siblings had none. That mixture is what made the checkout's record/restore load-bearing inside a workflow, and it let a basket half lapse: after a declined payment the later line sat on its own clock while the rest waited for the node timeout.

WorkflowHoldOwnership now owns the rule in one place: it suspends the existing lines when the starter hands the order over, and subscribes to BookingEvents::HELD for the ones held later. Nothing crosses the layering, since yoyaku only announces that a line was held and this module is the one that depends on Orchestra.

The result is that inside a workflow nothing is recorded and nothing is restored, so #3614466's mechanism now only ever does anything on a site running yoyaku without Orchestra. Places still come back either way: n_payment is PT20M with anchor: node, so cancelling and retrying never restarts it, and on expiry f_pay_to routes to n_release and yoyaku_cancel_order.

Both commits' tests were run against the unfixed code and seen to fail first. Whole yoyaku_orchestra suite (12 classes) plus core, order and payment (44 classes) green locally.