SL-393 Upgrade Saferpay API version from 1.50 to 1.53

[TLabutis]

What

Moves the module's declared Saferpay API spec version from 1.50 to 1.53 on every call, and makes SaferPayConfig::API_VERSION the single source of that version. The two configuration rows that used to carry it (SAFERPAY_SPEC_VERSION, SAFERPAY_SPEC_REFUND_VERSION) were seeded once at install time and never migrated, so upgraded shops kept declaring the version they were first installed with, and the refund request body could disagree with the shared request header. Both rows are removed by the 2.1.0 upgrade script.

Acceptance criteria evidence

AC	Criteria	Evidence
AC-1	All Saferpay API calls declare version 1.53	manual: 13 of 13 endpoints verified. 9 exercised through real sandbox flows (PaymentPage Initialize/Assert, Transaction Initialize/Authorize/Capture/Refund/Cancel, terminals, terminals/{id}), 4 closed with old-vs-new curl probes because no module flow reaches them (license, license-configuration, fields-access-tokens, AssertRefund)
AC-2	Existing shops migrated automatically, no merchant action	manual: proven on two shops. A throwaway PS 9.1.3 shop ran the real migration (install v2.0.3 with rows at 1.50, deploy branch, prestashop:module upgrade, rows deleted, every other SAFERPAY% row byte-identical including credentials). A tunnelled PS 9.1.0 shop still carrying the legacy 1.50 rows logged 1.53 on every request, proving the constant is the only source
AC-3	Payment flows regression-tested on test and live accounts	manual, partial: full regression on the TEST sandbox account (authorize, capture, refund, cancel). Live account run still needed, see below
AC-4	No merchant-visible behavior change	manual: identical request bodies answered identically under 1.50 and 1.53 in side-by-side probes

Tests

• php -l clean on all four changed PHP files.
• tests/Unit suite (PHPUnit 7.5 in the prestashop/prestashop:1.7.8-7.4 container): 3 tests, 1 pre-existing error in BasePaymentRestrictionValidationTest (constructor arity mismatch). The identical result occurs on the clean base commit 6d9be96c with this diff stashed, so it is a feature/react-admin-settings issue, not introduced here.

Manual verification

Real sandbox transactions on the JSON API TEST account: PaymentPage and Saferpay Fields payments authorized, captured, refunded and cancelled, with Saferpay Backoffice request logs confirming SpecVersion 1.53 on each call. Migration exercised end to end on a fresh 2.0.3 install upgraded to this branch.

Three findings during probing looked like 1.53 regressions and were each cleared by replaying the same body under 1.50 with an identical answer: the Notification.MerchantEmails validation failure (pre-existing module bug, separate ticket material), fields-access-tokens rejecting SourceUrls (caused by the http://localhost shop URL), and license-configuration answering ACTION_NOT_SUPPORTED on both versions (the module's /license fallback is unaffected).

Needs human verification

• AC-3 live-account half: a regression pass (authorize, capture, refund, cancel) on a LIVE Saferpay account. Only the TEST sandbox account was available during development.

Confidence: 90%