Resolve PHP test matrix from Composer constraints and setup-php stable availability

[coisa]

Context

The PHP test matrix is currently produced by .github/actions/php/resolve-version/action.yml from a hard-coded CI policy list:

SUPPORTED_MINORS = ["8.3", "8.4", "8.5"]

The resolver uses composer.lock / composer.json to infer the minimum PHP minor, then includes every hard-coded supported minor at or above that floor. The status publishing added for workflow-dispatched wiki pointer tests now reads the resolved matrix correctly, but the resolver itself still has two important limits:

• It does not honor upper bounds from composer.json constraints. For example, >=8.3 <8.5 currently resolves the floor as 8.3 and still runs 8.5.
• It does not discover new stable PHP minors automatically. For example, ^8.3 only runs through the hard-coded 8.5 until SUPPORTED_MINORS is edited manually.

The repository uses shivammathur/setup-php@v2 through .github/actions/php/setup-composer/action.yml, so the ideal improvement is to discover the latest stable PHP minor that this CI setup can actually install, then intersect that availability with the Composer PHP constraint.

Expected outcome

Improve the workflow PHP matrix resolver so it builds the matrix from both:

• the package's declared PHP constraint from Composer metadata; and
• the PHP minors that are stable and available to the setup-php based CI environment.

The resolver should avoid running PHP versions outside the package constraint while also reducing the maintenance burden when a new stable PHP minor becomes available.

Examples

• >=8.3 <8.5 should produce 8.3, 8.4 only.
• ^8.3 should produce every stable available PHP minor accepted by the constraint, currently up to the latest stable discovered by the resolver.
• If PHP 8.6 becomes stable and is available through the CI setup, ^8.3 should include 8.6 without manually editing a hard-coded list.
• If a constraint cannot be resolved safely, the workflow should retain a conservative fallback and explain the reason in the workflow summary.

Implementation notes

Investigate a reliable source for the latest stable PHP minors supported by the action/runtime before implementation. Possible directions include:

• querying metadata exposed by shivammathur/setup-php or its documented support policy;
• maintaining a small discovered/cached list generated by a script instead of a static inline constant;
• using Composer's own constraint parser where practical instead of ad-hoc regex parsing;
• adding a maximum CI policy guard if the project wants to opt out of newly released minors temporarily.

The final approach should keep workflow runs deterministic, avoid network fragility during every PR when possible, and still make the current matrix decision visible in the summary.

Acceptance criteria

• The test matrix resolver honors Composer lower and upper bounds when building the PHP matrix.
• The resolver can include the latest stable PHP minor available to the setup-php based environment without manually editing a hard-coded SUPPORTED_MINORS list for every release.
• Constraints such as >=8.3 <8.5, ^8.3, ~8.3, and explicit config.platform.php values are covered by tests or deterministic fixtures.
• The workflow summary continues to report the resolved PHP version source and the final matrix.
• When availability discovery fails, the resolver falls back conservatively and emits an actionable warning.
• Packaged consumer workflow behavior remains aligned with the canonical workflow.
• Documentation mentioning supported PHP versions or matrix behavior is updated to describe the new resolution policy.

Non-goals

• Do not add unstable, nightly, alpha, beta, or RC PHP versions to the default matrix.
• Do not run PHP minors outside the package's declared Composer PHP constraint.
• Do not make ordinary PR CI depend on an unreliable external API if the data can be cached or resolved deterministically.