1.8.2

Sends the capture's Cardcom deal number in outgoing payloads, not the hold's.

A Capture Charge on a suspended (J5) deal creates a NEW transaction with a new number at Cardcom; the original suspended deal keeps answering as a hold forever. Payloads built from a cached order instance in the same request as the capture still carried the pre-capture deal number, so Giorgio's charge verification queried the hold and raised false "charged 0" mismatch alarms on orders that were actually paid (Zano-Dagim). The Giorgio backend fix is already deployed; this completes the plugin side so the real charge transaction is sent and the amount can be verified.

resolve_cardcom_transaction_id_for_payload() reads the deal number from the newest database row, uncached (get_order_meta_values_uncached() — the same rule get_cardcom_capture_state() already uses), preferring Cardcom Payment ID then CardcomInternalDealNumber, and falls back to the previous cached read when the database has nothing (meta written on the in-memory instance but not yet saved). Used by the outgoing Order payload, the OrderPayment v2 payload, and the guard that holds the webhook back until a deal number exists.

Behaviour before a capture is unchanged: with a single meta row the newest row is the same row the old code read. One intentional difference — when Cardcom Payment ID holds 0 and CardcomInternalDealNumber holds a real number, the real number is now sent instead of 0, which stops the guard from deferring the webhook for no reason.

Not changed: the internalNumber field in the outgoing Order payload still comes from the cached read. Confirmed with the Giorgio backend that it does not bind that field in any model, does not store it, and never queries Cardcom with it — all lookups use payment.transactionId.

Syntax-checked against PHP 7.4 before release; the released tree is byte-identical to the reviewed branch.