Issue #3609746: Classify a failed capture, release or refund as retryable or declined

Makes a gateway's resolve/reversal operations classify their failures so a caller can tell a retryable failure from a permanent one.

• capture(), release() and refund() now return void and throw on failure: GatewayRetryableException when the provider cannot act on the transaction yet (the Worldline ACTION_NOT_ALLOWED_ON_TRANSACTION race, which a later retry clears), GatewayDeclinedException when it permanently refused.
• The Worldline gateway classifies each failure by its structured error code; the payment manager propagates the exception instead of swallowing it, so the payment state advances only on success.
• The create operations (authorize, chargeToken) keep their boolean return, since their outcome is recorded as the payment state.
• Drive-by: corrects the payment manager's event-dispatcher type hint (PSR to the Symfony interface Drupal's dispatcher implements), fixing pre-existing phpstan errors.

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.