DGS-442 Constrain bundled Symfony dependencies to supported PHP versions

[TLabutis]

Problem

Version 3.3.1 takes shops on PHP below 8.1 offline. On PHP 7.2 and 7.3 the whole shop returns a 500 immediately after installing, front office included, so the merchant cannot even reach the Modules page to uninstall.

Root cause

invertus/dpdbaltics-api declares three Symfony packages as unconstrained wildcards:

"symfony/property-access": "*",
"symfony/property-info":   "*",
"symfony/serializer":      "*",

The module's own composer.json constrained only symfony/console, so nothing bounded those three. DGS-430 then added --ignore-platform-reqs to the release build, which discards the config.platform.php = 5.6 pin, and Composer resolved the wildcards to whatever was newest at build time.

Comparing the published v3.3.1 asset against the known good 3.3.0 build:

Package	Published 3.3.1	3.3.0	Requires
symfony/serializer	v8.0.3	v3.4.47	php >=8.4
symfony/property-access	v6.4.25	v3.4.47	php >=8.1
symfony/string	v6.4.34	absent	php >=8.1
symfony/deprecation-contracts	v3.6.0	absent	php >=8.1
symfony/debug	v4.4.44	v3.4.47	php >=7.1.3
prestashop/decimal	1.5.0	1.4.0	php >=7.2

27 packages shipped instead of 23. symfony/serializer v8.0.3 requiring PHP 8.4 is what white-screens the shop.

The drift is also committed: composer.lock on main already holds those versions, so composer install reproduces the broken build faithfully. This is not only a build-time accident.

Changes

1. composer.json - explicit ^3.4 constraints for symfony/serializer, symfony/property-access, symfony/property-info and symfony/debug. Root constraints override transitive ones, so this bounds the wildcards without needing a change in the API package.
2. composer.lock - regenerated against the 5.6 platform pin. Back to 23 packages, all PHP 5.6 compatible. invertus/dpdbaltics-api and invertus/psModuleTabs stay pinned at their existing refs, so no API behaviour changes ride along with this fix.
3. release.yml / create-zip.yml - dropped --ignore-platform-reqs so Composer's platform verification runs again.
4. dpdbaltics.php - install() is guarded behind a new MINIMUM_PHP_VERSION constant, so an unsupported PHP is refused with a readable message instead of taking the shop offline. There was no check of any kind before.

Verification

Simulating the CI build locally:

Lock file	composer install --no-dev exit code
Old (on main)	4 - fails, naming all four drifted packages
New (this branch)	0 - passes

So the restored platform check does catch this class of problem before publishing, which was point 3 of the ticket.

Still open

• The A/B decision in the ticket is not made here. MINIMUM_PHP_VERSION is set to the currently advertised 5.6. If we go with Option B (require PHP 8.1+), it is a one line change plus the stated requirements, changelog and store listing.
• Module version stays 3.3.1; bumping to 3.3.2 belongs to the release PR.
• The constructor's autoLoad()/compile() path is untouched, so this does not rescue a shop that already installed 3.3.1. The documented workaround stays: install 3.3.0.
• Notifying affected merchants who already installed 3.3.1 is not covered here.

How to test

Install the built package on PHP 7.2, 7.4, 8.0 and 8.1. In each case the shop should load, and creating a shipment, printing a label and loading pickup points should all work.

Related: DGS-440 (where this was found), DGS-430 and SDESK-232 (release build).