Refund a captured booking payment when the operator rejects the booking

On the manual-validation path of the booking example workflow, when the operator rejects a booking that already carries a captured payment, the booking is released but the payment is never refunded. The customer is left out of pocket for a booking that never went ahead.

Proposed resolution

Add a refund step on the rejection branch. When the operator rejects the booking, any captured booking payment is refunded before the release notification is sent. The refund is unconditional of the resource refund deadline: a late validation is not the customer's fault, so a rejection always refunds.

The release notification mentions the refund only when an amount was actually returned, so a free or unpaid booking says nothing about a refund.

Cross-project dependency

The refund is issued by a workflow action on a token-pinned payment. That relies on the payment workflow bridge claiming the refund event so the booking release stays driven by the run rather than by the autonomous cancel-on-refund reaction. That fix lives in orchestra: see #3609403. This must land in orchestra 1.x before the functional test here passes in CI.

Tests

A functional end-to-end test drives the manual resource through payment to operator rejection and asserts the payment is refunded, the booking released and the instance completed.

Note

A second commit synchronizes the shipped BPMN diagram with the modeler layout saved on the reference site. It is presentation only: no node, flow or executable config changes.