Fix release builds blocked by Composer security advisories

[TLabutis]

Problem

No release can currently be built, from any branch. release.yml, deploy.yml and create_zip.yml all run the same composer install --no-dev line, and it fails with exit 2:

No composer.lock file present. Updating dependencies to latest instead of installing from lock file.
Your requirements could not be resolved to an installable set of packages.
  - symfony/yaml ^3.4 ... affected by security advisories ("PKSA-v5yj-8nmz-sk2q", "PKSA-ft77-7h5f-p3r6", "PKSA-b14r-zh1d-vdrc")
  - phpunit/phpunit ^7.5 ... ("PKSA-z3gr-8qht-p93v")
  - symfony/process ^3.4 ... ("PKSA-rkkf-636k-qjb3", "PKSA-wws7-mr54-jsny")
  - friendsofphp/php-cs-fixer ^2.16.7 -> requires blocked symfony/process

Two things combine to cause it:

1. Composer 2.10 refuses to resolve packages carrying security advisories.
2. composer.lock was gitignored, so every pipeline resolved from scratch and hit that block on every run.

--no-dev does not avoid it, because dev requirements still participate in resolution even when they are not installed. The existing config.audit.ignore does not help either: it suppresses composer audit output, not the resolver's policy.advisories block.

This is pre-existing and unrelated to the settings redesign. master has the identical composer.json and gitignored lock. The last four releases up to v2.0.3 (2026-06-25) all succeeded, so this broke after that, when Composer shipped advisory blocking, and no release has been cut since.

Fix

• Track composer.lock. With a lock present, pipelines install pinned versions and never resolve, so the advisory block does not apply. This is also correct for a module that ships vendor/: releases become reproducible instead of resolving to whatever is newest at build time.
• Record the advisory IDs in config.policy.advisories.ignore-id. Without this, the lock could never be regenerated by a developer without a manual bypass. The affected packages are the deliberately pinned Symfony 3.4 / PHPUnit 7.5 dev stack, kept for PS 1.6/1.7 and PHP 7.1 compatibility, so ignoring these specific IDs is a recorded decision rather than a blanket policy.advisories.block: false.

The lock was generated with Composer 2.10.2 against config.platform.php: 7.1, so resolution targets the module's real PHP floor rather than the build machine's PHP.

Verification

Every claim below was executed, not assumed.

1. composer install --no-dev from the lock, on Composer 2.10.2 (same generation as the runner) - exit 0, installs symfony/yaml v3.4.47 without complaint. This is the load-bearing check: it confirms the block is on resolution, not installation.

2. composer update --no-install with the ignore-ids, on Composer 2.10.2 - exit 0, reporting Found 6 ignored security vulnerability advisories affecting 3 packages. Confirms the lock stays regenerable.

3. Full create_zip.yml recipe end to end, from a clean clone of this branch (so no gitignored build output could leak in), node 20 / pnpm 9 for the app and Composer 2.10.2 for packaging:

../dist/saferpay-settings.js   328.72 kB    <- React bundle built
Generated optimized autoload files (authoritative) containing 545 classes
### ARTIFACT VERIFICATION
artifact root: saferpayofficial
-- react bundle --   saferpay-settings.js 328723, saferpay-settings.css 28259
-- vendor --         vendor/autoload.php, vendor/.htaccess
-- dev deps --       phpunit absent (correct for --no-dev)
-- entrypoint --     saferpayofficial.php

So the artifact now contains both the compiled settings app and a production vendor/.

Notes

• No changelog entry. This changes the build pipeline only, with no user-facing behaviour, matching the precedent of the React build PR (Internal/ci build react settings #330). Happy to add one if you would rather every PR carry an entry.
• composer.lock and composer.json now ship inside the ZIP, since neither is in the packaging step's rm -rf list. Harmless, but it can be added there if you prefer a leaner artifact.
• Separately worth a ticket, not fixed here: symfony/yaml ^3.4 sits in require, not require-dev, and carries three advisories. Symfony 3.4 has been EOL since November 2021, so production ships an unmaintained YAML parser. Bumping it touches the php >=7.1 floor and PS 1.6/1.7 compatibility, so it is a deliberate decision rather than part of a build fix.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.