Infer PHP version for wiki and reports workflows

[coisa]

Problem

The wiki, reports, and tests workflows currently assume PHP 8.3 as a fixed baseline. Wiki and reports install PHP 8.3 explicitly before running Composer and dev-tools commands, while the tests workflow always includes 8.3 in its matrix.

Consumer repositories can require PHP 8.4+ or newer in composer.json or composer.lock, which can make composer install fail or make the test matrix run impossible jobs below the package's declared minimum platform.

Current Behavior

.github/workflows/wiki.yml and .github/workflows/reports.yml use a hard-coded PHP version:

php-version: '8.3'

.github/workflows/tests.yml uses a hard-coded matrix:

php-version: [ '8.3', '8.4', '8.5' ]

The packaged workflow stubs call these reusable workflows, so downstream repositories inherit the same behavior.

Expected Behavior

Wiki and reports workflows should infer the PHP version required by the consumer repository before running shivammathur/setup-php, Composer install, and dev-tools commands.

The tests workflow should infer the package's minimum supported PHP minor version and build its matrix from that minimum upward. For example, a package requiring php: ^8.4 should test 8.4 and newer supported minors, but not 8.3.

When the PHP version cannot be inferred safely, workflows should fall back to 8.3 to preserve current behavior.

Failure Surface

• .github/workflows/wiki.yml
• .github/workflows/reports.yml
• .github/workflows/tests.yml
• resources/github-actions/wiki.yml
• resources/github-actions/reports.yml
• resources/github-actions/tests.yml
• Consumer repositories with composer.json or composer.lock declaring PHP 8.4+ or newer

Proposal

Add a reusable PHP version resolution step or script for GitHub Actions workflows. The resolver should inspect the checked-out repository and expose outputs consumed by shivammathur/setup-php and the test matrix.

The resolver should consider, in priority order:

1. composer.lock platform PHP version when present and versioned.
2. composer.json config.platform.php when present.
3. composer.json require.php constraints when they imply a minimum supported PHP minor version.
4. Fallback to 8.3 when no reliable version can be inferred.

For test matrices, the resolver should produce a JSON matrix that starts at the inferred minimum and includes known supported PHP minors for this repository's CI policy.

Requirements

• The inferred version must be logged in workflow output.
• Wiki and reports must use the inferred version for Composer installation and command execution.
• Tests must not include PHP versions lower than the inferred minimum supported version.
• The implementation must support at least constraints that imply PHP 8.3, 8.4, or 8.5.
• Invalid or unsupported constraints must fall back to 8.3 with a clear warning.
• Consumer workflow stubs should not need to duplicate the inference logic.

Non-goals

• Building a complete Composer constraint solver in shell.
• Changing package PHP constraints.
• Replacing shivammathur/setup-php.
• Expanding the maximum PHP version beyond the repository's supported CI policy in this issue.

Acceptance Criteria

Functional Criteria

• Reports workflow uses an inferred PHP version instead of hard-coded 8.3.
• Wiki workflow uses an inferred PHP version instead of hard-coded 8.3.
• Tests workflow builds its PHP matrix from the inferred minimum supported PHP version.
• A repository with composer.json requiring php: ^8.4 runs reports/wiki setup with PHP 8.4 or newer-compatible configured version.
• A repository with composer.json requiring php: ^8.4 does not include PHP 8.3 in the test matrix.
• A repository with composer.json requiring php: >=8.5 runs reports/wiki setup with PHP 8.5 or newer-compatible configured version.
• A repository with composer.json requiring php: >=8.5 does not include PHP 8.3 or 8.4 in the test matrix.
• A repository with config.platform.php uses that platform PHP version when no lock platform value overrides it.
• A repository with no parseable PHP requirement falls back to PHP 8.3 and the current default test matrix behavior.
• Workflow logs clearly show the detected source and final PHP version or matrix.

Regression Criteria

• Existing repositories without PHP 8.4+ requirements continue to run with PHP 8.3 by default.
• Packaged consumer workflow stubs remain small and continue calling the reusable workflows.
• Composer cache keys remain stable or intentionally include the resolved PHP version if needed.
• Workflow validation covers the new shell/script logic.

Architectural / Isolation Criteria

• PHP version resolution is implemented once and reused by wiki, reports, and tests where practical.
• The resolver is deterministic and does not require network access.
• The workflow remains readable and safe for pull request preview events.