The Drupal 10.6 test lane cannot build: a require-dev dependency needs PHP 8.3

Problem/Motivation

The module declares core_version_requirement: ^10.6 || ^11.3, but until now CI only ran against current core — neither floor was ever exercised, so the green pipeline did not mean what it appeared to. Opting the previous-major and previous-minor jobs in surfaced this immediately.

Result: Drupal 11.3 passes 520/520, same as current core. The Drupal 10.6 lane cannot build at all:

drupalConstraint=10.6.13 (from DRUPAL_CORE)
Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - Root composer.json requires drupal/mcp_server ^2.0@dev
    - drupal/mcp_server[2.0.0-alpha1, ..., 2.x-dev] require php ^8.3
      -> your php version (8.1.34) does not satisfy that requirement.

The composer (previous major) job fails in the build stage with exit code 2, so phpunit (previous major) never runs and produces no test report.

What this is, and what it is not

Worth being precise, because the first reading is worse than the truth.

The ^10.6 support claim is not false. drupal/mcp_server is in require-dev, not require — it is a test-only dependency, and it is listed under suggest for real installs. The runtime requirements (key, simple_oauth, consumers, encrypt, tool) carry no PHP 8.3 constraint, so a Drupal 10.6 site on PHP 8.1 can install and run this module.

What is broken is the ability to verify that. The DA test build installs require-dev, so the whole suite is unbuildable on the lane that uses Drupal 10's minimum PHP. The claim is plausible but unproven, which under our own standard is not a claim.

Secondary observation: composer.json declares no php constraint at all. Composer therefore infers no floor from the module itself, and the effective floor comes only from whatever core requires. That is worth stating explicitly regardless of how this issue is resolved.

Proposed resolution

Three options, and they are not equivalent.

A — run the previous-major lane on PHP 8.3 (_TARGET_PHP: '8.3' on that job). Drupal 10.6 supports PHP 8.1 through 8.4, so 10.6-on-8.3 is a legitimate, representative configuration, and it is the one where the suite can actually run. Cheapest, and it makes the Drupal claim verified. Leaves 10.6-on-PHP-8.1 untested.

B — keep the dev dependency off the old lane. Move drupal/mcp_server out of require-dev and inject it per-job via _PHPUNIT_EXTRA_DEPENDENCIES only where PHP satisfies it, skipping the mcp_sentinel_server tests on 10.6/8.1. Tests the true floor, at the cost of reduced coverage on that lane and more CI config to keep honest.

C — declare the real floor. If the intent is that this module is PHP 8.3+ in practice, say so with an explicit "php" constraint and accept that the D10-on-8.1 combination is unsupported. Honest, but narrows support, and our standard says do not narrow a claim for convenience — so this needs a reason beyond CI being awkward.

Leaning A plus the explicit php constraint: it makes the Drupal support claim genuinely verified, and stating the PHP floor removes the ambiguity about what is actually supported rather than leaving it implied.

Remaining tasks

• Decide A, B or C.
• Apply the CI change and confirm phpunit (previous major) produces a green test report rather than no report.
• Add an explicit php constraint to composer.json reflecting whatever floor is chosen.
• Note the outcome in the README's requirements section, which currently states the Drupal range but not a PHP range.

User interface changes

None.

API changes

None, unless option C is chosen, in which case the supported-PHP surface narrows.

Data model changes

None.

Also surfaced by the same first-time run, and worth separate issues rather than being bundled here: the phpstan job reports 41 findings, including 6 × "DependencySerializationTrait does not support private properties" and 6 × the read-only variant — the same serialisation family being tracked for File Gate at #3613925 — plus 10 × a fetchAll() argument-type mismatch. The cspell job also wants a few project words. All three jobs are allow_failure, so none of them gates the pipeline.