Classify a failed capture, release or refund as retryable or declined

A payment gateway capture, release and refund report failure as a bare boolean, so a caller learns only that the operation failed, not whether it can succeed on a retry. A Worldline capture or cancel run just after an authorization can be refused only because the transaction has not settled into a state that allows it yet (error 50001127, ACTION_NOT_ALLOWED_ON_TRANSACTION), and a later retry succeeds. That is indistinguishable from a permanent decline today.

This changes capture(), release() and refund() to return void and throw a typed exception on failure: GatewayRetryableException when the provider cannot act on the transaction yet, GatewayDeclinedException when it permanently refused. The Worldline gateway classifies each failure by its structured error, and the payment manager propagates the exception instead of swallowing it, advancing the payment state only on success. A caller such as a workflow settlement step can then retry the transient case and escalate the permanent one.

The create operations (authorize, chargeToken) keep their boolean return, since their outcome is recorded as the payment state. Kernel tests cover the manager propagating a decline out of captureHold, releaseHold and refund, and the Worldline gateway mapping a transient error code to retryable and any other to declined.