Add matomo6_min_php and matomo6_max_php PHP version aliases

[snake14]

Description

Adds matomo6_min_php and matomo6_max_php aliases, resolving to PHP 8.1 (the Matomo 6 minimum) and PHP 8.5, alongside the existing matomo5_* aliases. Plugin repositories' Matomo 6 branches can then switch their test matrices with a mechanical matomo5_ → matomo6_ rename while the supported PHP range stays centrally managed here, matching how the Matomo 5 aliases are used today. First consumer is the ActivityLog Matomo 6 branch (PG-5380).

Checklist

• [✔] I have understood, reviewed, and tested all AI outputs before use
• [✔] All AI instructions respect security, IP, and privacy rules

Review

• Functional review done
• Potential edge cases thought about (behaviour of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• New documentation added or existing documentation updated

[snake14]

@matomo-org/core-reviewers @matomo-org/plugin-reviewers @matomo-org/innovation-reviewers
Before we roll this out to all plugin repos for Matomo 6, I'd like feedback on where PHP versions should live long-term — this PR unblocks the ActivityLog pilot either way, but the fleet-wide sweep should land on the pattern we actually want to maintain.

A few observations from preparing the pilot:

• The alias table is a third copy of the truth: core already declares its PHP floor (core/testMinimumPhpVersion.php / composer.json), and generate:test-action has its own LATEST_PHP_VERSION and emits concrete versions rather than aliases. These copies already drift — the fleet's workflows use aliases the generator doesn't produce, and e.g. ActivityLog's workflow header still records --php-versions="7.2,8.4" while matomo5_max_php resolves to 8.5.

• Add a reusable PHPStan workflow and the canonical pre-push hook, PG-4897 #44/Add reusable PHPCS and AI-checklist workflows for plugin repos, PG-4897 #45/Add reusable license check workflow for plugin repos #46 already move the PHPStan/PHPCS/AI-checklist/license workflows here as reusable workflows, which solves the pipeline-shape duplication for those. But php-version remains a caller-side input there (PHPCS defaulting to 7.4, passed straight to setup-php), so a future PHP bump still means a PR to every caller repo — the version question survives centralisation unless the reusable workflows resolve the aliases (or derive the floor) themselves.

• Only the minimum actually varies per major: matomo5_max_php and matomo6_max_php both resolve to 8.5. "Max" is a fleet-wide policy value, while "min" is derivable — the action already checks out the target Matomo, which contains its own floor.

Options as I see them:

1. Keep per-major aliases (this PR) — smallest change, consistent with today's convention, and needed to unblock the pilot regardless.

2. A versionless matomo_min_php resolved at runtime from the target Matomo checkout, plus a single matomo_max_php policy value — no new aliases needed for future majors, and min can't drift from core.

3. Extend the workflow_call pattern from Add a reusable PHPStan workflow and the canonical pre-push hook, PG-4897 #44–Add reusable license check workflow for plugin repos #46 to the test matrix. The test steps are already central (the composite action), but a composite action runs inside a job the caller defines, so the matrix — the PHP × Matomo-target lists, cron, artifact conditions, exactly the part that changes when PHP support changes — still lives in every plugin repo. A reusable workflow here owning the matrix (and resolving/deriving the PHP versions internally) would shrink each plugin's matomo-tests.yml to a thin trigger-only caller.

Related either way: plugin workflows reference this repo @main, so a single merge here can break every plugin's CI at once — worth considering tagged refs or a per-major branch as we centralise more logic.

Opinions? Happy to prepare whichever direction we pick before the sweep starts.

[AltamashShaikh]

LGTM

[AltamashShaikh]

@snake14 The versions should live here, so that when we want to increase the PHP_MAX_VERSION we increase it at 1 place.