Follow orchestra's result vocabulary split: payload variable, completion scope, outcome

Follows [#3613729], which split orchestra's overloaded result vocabulary into the outcome (the resolved decision an outgoing flow condition routes on) and the completion payload (whatever complete() or a resume was called with).

What moved

• result_variable to payload_variable and result_scope to completion_scope: the yoyaku_booking example workflow (node config and the BPMN XML it embeds, so a modeler round-trip stays stable) plus the kernel tests that build workflows inline.
• ProcessControlInterface::resumeWithResult() to resumeWithPayload(), called by BookingProcessCorrelator and one functional test. The correlator's own $result parameters become $payload, with its interface documentation and its "no parked step" log placeholder.
• The payment actions' RESULT_VARIABLE constant becomes OUTCOME_VARIABLE and the shared setResult() helper becomes setOutcome(): each writes a single decision a flow branches on, so this side of the split is the outcome, not the payload.
• Example variable names holding a scalar outcome follow the upstream ones: cancel_result, cancel_order_result, confirm_result, form_result, payment_result, release_result, settle_result, yoyaku_deposit_result and yoyaku_no_show_result become *_outcome.

Notes

Docs move with the code (docs/orchestra.md named yoyaku_deposit_result). Pre-release on both sides, so no update hooks: a site's saved workflows, its orchestra.settings and any process variable holding a payload under the old result key are rewritten by hand.