Filter composition ordering

[wol-soft]

Summary

This PR fixes the ordering of validators relative to transforming filters and adds static
rejection of composition/filter combinations that cannot produce correct runtime behavior.

Without this fix, a property with a transforming filter (e.g. string -> DateTime) and a
composition keyword (e.g. allOf, anyOf, if/then/else) would run all validators
post-transform -- meaning type constraints meant to apply to the raw input value were
silently evaluated against the already-converted output. The reverse was true for output-space
constraints when no guard prevented them from firing pre-transform.

---

What changed

Phase 1 - Branch classifier and Draft registry extension

• Draft::getTypesForKeyword(string $keyword): string[] maps any JSON Schema keyword to the
  Draft type names whose modifier/factory list carries it, enabling type-space lookup without
  hard-coded keyword tables.
• AbstractValidatorFactory::getKey(): ?string exposes the source keyword stored on each
  validator factory, providing the backlink needed to trace a live validator to its origin.
• TypeSpace enum (Input / Output / Mixed / Empty) as the classification result type.
• CompositionBranchClassifier classifies a single composition branch relative to a
  transforming filter's input/output type-spaces. Uses the Draft registry for extensibility;
  defaults ambiguous branches to Input (conservative policy).

Phase 2 - Static compatibility checking

• CompositionCompatibilityChecker with two responsibilities:
  • Validates that composition keywords on a filtered property do not create unresolvable
    type-space conflicts (allOf Mixed branch, cross-space anyOf/oneOf branches,
    Mixed not, cross-space if/then/else sub-schemas).
  • Enforces that root-level composition branches do not constrain the filtered sub-property
    with output-type-space constraints (R-4).
• checkForFilterInBranches added to AbstractCompositionValidatorFactory to reject the
  filter keyword inside any composition branch (R-7) universally across all five factories.

Phase 3 - Validator priority reassignment

• Validator gains a sourceKey field so any validator wrapper can be traced back to its
  originating JSON Schema keyword.
• PropertyFactory.applyModifiers() tags newly-added validators with the factory's schema key
  immediately after each AbstractValidatorFactory runs.
• FilterProcessor::reassignValidatorPriorities() moves input-space validators (those whose
  source keyword belongs to the filter's input type-space) to priority P-1, so they fire
  against the raw value before the filter runs. Output-space validators remain post-transform.

Phase 4 - Composition runtime integration

• Composition validators are split around the transforming filter boundary: input-space
  branches run pre-transform; output-space branches run post-transform.
• FilterPreTransformGuardValidator wraps any input-space composition validator with a skip
  guard that returns early when the value is already in the filter's output type-space
  (already-transformed passthrough).
• ComposedPropertyValidator gains createSubsetValidator() to split a mixed-space allOf
  into a pre-filter input-subset and a post-filter output-subset.
• FilterProcessor decomposed into three focused private methods
  (classifyValidatorAdjustments, wrapInputSpaceGuards, splitMixedSpaceAllOf).

Phase 5 - FormatValidator type guard

• FormatValidator.getCheck() now prepends is_string($value) && to its generated check,
  matching the existing pattern of every other string-space validator (pattern, minLength,
  maxLength). Without this guard, a multi-type property with a format validator and a
  transforming filter would call FormatValidatorFromRegEx::validate(int) under strict types
  when an already-transformed integer was passed, throwing TypeError instead of the expected
  post-transform validation exception.

Phase 6 - Test quality

• Replaced a ReflectionClass workaround in testAllOfPropertyWithMixedAcceptTransformingFilter
  with three direct runtime assertions: valid string input -> transform -> DateTime;
  integer input -> AllOfException; already-constructed DateTime -> passthrough.

Phase 7 - Property-level composition type semantics and documentation

• allOf on a property now uses intersection semantics: conflicting branch types throw
  SchemaException; int|number resolves to int via the integer-subtype-of-number rule,
  centralised in the new TypeIntersection::compute utility.
• anyOf/oneOf with a truly untyped branch ({}) correctly leaves the property as mixed
  instead of wrongly adding nullable=true.
• Property-level if/then/else gains type widening (union of then+else types when the
  parent has no declared type) and conflict detection (SchemaException when the parent type
  is incompatible with both branches).
• TypeIntersection::compute extracted as a standalone PHPModelGenerator\Utils utility.
• filter.rst updated with a new "Composition with transforming filters" section covering
  branch classification, accepted and rejected combinations, and correct type keyword usage.
• CompositionBranchClassifier: type keyword now always classifies as Input -- it
  validates raw JSON input and must never be routed against output types.

Fix - if/then/else branch conflict detection

• IfValidatorFactory previously required both branches to conflict with the parent before
  throwing, and stripped null from parent type names -- so a null-typed branch against a
  non-null parent was silently accepted.
• Each branch is now checked independently; isNullable() is included in the parent set.
• getBranchTypeNames() distinguishes null-typed branches ({type: null}) from truly untyped
  branches via getTypeHint(), so null-typed branches correctly intersect (or conflict) with
  the parent type.

Test suite refactor - FilterTest split

• The monolithic Basic/FilterTest (~3050 lines) is replaced by eight focused classes under
  tests/Filter/, each covering one concern: configuration, built-in filters, custom filters,
  transforming filters, type compatibility, filter chains, static composition checks, and
  runtime composition ordering.

---

Test plan

• ./vendor/bin/phpunit -- full suite green
• ./vendor/bin/phpunit tests/Filter/ -- all eight focused filter test classes pass
• ./vendor/bin/phpunit tests/ComposedValue/ -- composition tests unaffected
• Static rejection tests confirm SchemaException for all rejected filter+composition
  combinations enumerated in rejectedCompositionProvider
• Runtime ordering tests confirm pre/post-transform validator sequencing for all
  composition types in FilterCompositionRuntimeTest
• if/then/else null-typed branch conflict detection tested for all new edge cases

Generated with Claude Code

[coveralls]

Coverage Report for CI Build 26169686326

Coverage decreased (-0.07%) to 98.483%

Details

• Coverage decreased (-0.07%) from the base build.
• Patch coverage: 19 uncovered changes across 6 files (771 of 790 lines covered, 97.59%).
• No coverage regressions found.

Uncovered Changes

File	Changed	Covered	%
src/PropertyProcessor/Filter/FilterProcessor.php	220	212	96.36%
src/PropertyProcessor/Filter/CompositionCompatibilityChecker.php	152	146	96.05%
src/Model/Property/PropertyProxy.php	2	0	0.0%
src/Model/Validator/Factory/Composition/IfValidatorFactory.php	69	68	98.55%
src/Model/Validator/FilterValidator.php	44	43	97.73%
src/PropertyProcessor/Filter/CompositionBranchClassifier.php	90	89	98.89%

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	5538
Covered Lines:	5454
Line Coverage:	98.48%
Coverage Strength:	594.2 hits per line

---

💛 - Coveralls