[PAR-778] Bump integration-core to ~5.3.0

[mescalantea]

What is the goal?

Bumps sequra/integration-core from ~5.2.0 to ~5.3.0. v5.3.0 introduces an optional StoreUrlProviderInterface (sequra/integration-core#62) that lets integrations expose a cheap getStoreUrl() lookup for the webhook HMAC payload, avoiding the cost of building a full StoreInfo on every register, delete and inbound webhook validation.

The bump is fully backwards-compatible: StoreUrlProviderInterface is a new optional companion to StoreInfoServiceInterface, and StoreInfoServiceInterface itself is unchanged — no integrator is forced to change anything to upgrade.

References

• Issue: PAR-778
• Related pull-requests: [PAR-778] Avoid full StoreInfo computation when only storeUrl is needed for HMAC integration-core#62

How is it being implemented?

• Composer constraint bumped from ~5.2.0 to ~5.3.0.
• composer.lock refreshed via composer update sequra/integration-core --with-dependencies. Only the core itself moved (v5.2.0 → v5.3.0); no transitive churn.
• No middleware src/ change. The new interface is a downstream integrator-level opt-in; the middleware itself does not provide a StoreInfoServiceInterface implementation, so nothing here needs to opt in.

Caveats

• Integrators implementing StoreInfoServiceInterface do not need to change anything to upgrade — the new interface is pure opt-in.
• Integrators whose getStoreInfo() is expensive (live API calls to populate fields the HMAC does not use) can adopt by adding implements StoreUrlProviderInterface alongside their existing StoreInfoServiceInterface and returning a cheap storeUrl string. Signatures are byte-identical across both paths, so adoption never invalidates a previously-issued webhook URL.

Does it affect (changes or update) any sensitive data?

No — this change only touches composer.json / composer.lock. The HMAC payload, signature secret and inbound webhook validation behaviour upstream are unchanged.

How is it tested?

• composer validate --strict passes after the bump.
• vendor/bin/phpunit was not re-run locally (the local test env is not bootstrapped — pre-existing limitation unchanged by this PR). The middleware src/ is untouched, so existing tests are not affected.

How is it going to be deployed?

Standard deployment. Tag the next minor (v3.2.0) once merged; downstream integrators pick it up via their existing ^3.0 constraints on sequra/middleware.