chore: add release split and consumer validation

[josiahking]

Summary

Implements EvolvePHP 2 Phase 2.10B: deterministic package-split validation and offline prerelease/stable Composer consumer validation.

This phase validates future package release boundaries without publishing packages, creating remote package repositories, creating source tags, registering Packagist packages, or adding release automation.

Package Split Validation

Adds:

composer --working-dir=workspace release:split:validate

The validator:

• reads the canonical six-package release map
• creates a disposable independent Git clone
• runs git subtree split twice per package
• verifies deterministic split SHAs
• verifies exact source-subtree/split-root tree equality
• verifies exact file-inventory equality
• validates generated split-root Composer manifests
• preserves package-specific Git history
• mutates no source repository state
• creates no remote repositories or source tags

The deterministic split validation now runs inside the existing required:

Policy (PHP 8.4)

job before supply-chain validation.

Prerelease Consumer Validation

Adds:

composer --working-dir=workspace release:consumer:validate

The validator creates disposable local VCS package repositories and reproduces
the accepted Composer solver matrix using isolated:

• 2.0.0-alpha.1
• 2.0.0

package sets.

Packagist and Composer network access are disabled during the fixtures.

The eight cases verify:

• exact alpha under default stability fails for transitive alpha dependencies
• top-level @alpha alone does not propagate through transitive dependencies
• root minimum-stability: alpha with prefer-stable: true succeeds
• explicit root alpha flags succeed
• full testing-package graph behaves consistently
• stable 2.0.0 resolves normally under default stability

The consumer validator remains manual/pre-release and is intentionally not a
required CI step.

Composer Constraint Result

The existing first-party internal constraints remain:

^2.0

No package Composer manifest was modified.

No package gained:

• @alpha
• minimum-stability
• prefer-stable
• hard-coded version

The prerelease behavior is a root-consumer stability-policy concern, not an
internal package-constraint defect.

CI Policy Evolution

The existing architecture policy previously prohibited the literal word
release anywhere in the workflow.

That policy was narrowed so that:

• release validation is allowed
• release publication remains forbidden

The existing required CI job identities remain unchanged:

• Policy (PHP 8.4)
• Workspace quality (PHP 8.4)
• Workspace quality (PHP 8.5)

Validation

• targeted Phase 2.10B: 9 tests, 165 assertions
• Documentation: 126 tests, 1672 assertions
• Architecture: 47 tests, 3217 assertions
• complete root: 173 tests, 4889 assertions
• PHP 8.4 policy: 173 tests, 4889 assertions
• workspace PHPUnit: 6 tests, 18 assertions
• Deptrac: 0 violations
• PHPStan: no errors
• PHP-CS-Fixer: 0 fixable files
• aggregate quality: passed
• supply-chain: passed
• six package Composer manifests: strict valid
• split validator: passed repeatedly
• consumer validator: all eight expected outcomes passed
• root/workspace lockfiles unchanged
• source tags unchanged

Scope

Exactly 9 files:

• 4 added
• 5 modified
• 1,245 insertions
• 2 deletions

No dependencies, package manifests, lockfiles, RFCs, repository settings,
remote repositories, Packagist registrations, source tags or releases changed.

Deferred

Still deferred beyond Phase 2.10:

• creation of remote split repositories
• repository ownership/naming
• Packagist registration
• actual package tags
• GitHub releases
• package publication
• signing/provenance
• release orchestration