[PAR-778] Bump integration-core to ~5.2.0 for active_theme support in store info payload

[mescalantea]

What is the goal?

Bumps sequra/integration-core from ^5.1.3 to ~5.2.0. v5.2.0 introduces an optional active_theme property on the store info payload (StoreInfo) so downstream integrators can surface the merchant's currently active storefront theme alongside the existing platform/plugin/php/db/os fields.

The bump is fully backwards-compatible: activeTheme is an optional trailing constructor arg defaulting to null, and StoreInfoServiceInterface is unchanged — no integrator is forced to change anything to upgrade.

References

• Issue: PAR-778

How is it being implemented?

• Composer constraint bumped from ^5.1.3 to ~5.2.0 (patch-only range within 5.2.x, more conservative than the prior ^ style on the 5.1.3 bump).
• composer.lock refreshed via composer update sequra/integration-core --with-all-dependencies. Only the core itself moved (v5.1.3 → v5.2.0); no transitive churn.
• Audited src/BootstrapComponent.php::initRepositories() against vendor/sequra/integration-core/src/BusinessLogic/DataAccess/. 5.2.0 introduces no new persisted entity; all 12 DataAccess entities remain registered. No bootstrap change needed (unlike the prior 5.1.3 bump which had to register AdvancedSettings).
• Verified the 5.2.0 StoreInfo shape in vendor/sequra/integration-core/src/BusinessLogic/Domain/Stores/Models/StoreInfo.php: new optional 10th constructor arg ?string $activeTheme = null, new getter getActiveTheme(): ?string, toArray()/fromArray() round-trip the active_theme key. StoreInfoServiceInterface::getStoreInfo() signature is unchanged.

Caveats

• Downstream integrators implementing StoreInfoServiceInterface do not need to change anything to upgrade — activeTheme is optional and defaults to null.
• To populate the new field, integrators pass the theme name as the 10th constructor arg of StoreInfo; existing call sites continue to compile and run unchanged.

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

No — this change only touches composer.json / composer.lock. No schema migrations, no payload-handling code in this middleware.

How is it tested?

• composer validate passes after the bump.
• vendor/bin/phpunit was not re-run locally for this bump (the local test env is not bootstrapped). The middleware src/ is untouched by this change — only the composer manifest and lock — so existing repository/logger tests are not affected. Please re-run the suite as part of standard review if desired.

How is it going to be deployed?

Standard deployment.

Commits

• baeceb9 PAR-778: step 2 - refresh composer.lock to integration-core v5.2.0
• 14ecd61 PAR-778: step 1 - bump integration-core constraint to ~5.2.0

🤖 Generated with Claude Code