fix #920: no type change when array is wrapped in allOf

[DrSatyr]

Fixes #920. Follow-up to #916.

Comparing a direct type: array against an allOf-wrapped array reported a spurious breaking change between two equivalent specs:

* Changed property `valuations` (array -> array)

#### Result
API changes broke backward compatibility

SchemaDiff#computeDiffForReal picks the diff result from right.getClass(). resolveComposedSchema merges allOf members into the parent but leaves the instance a ComposedSchema, so with the allOf spec on the right, ComposedSchemaDiffResult was selected and its else branch reported a type change because left was an ArraySchema rather than a ComposedSchema — even though the type/format equality check upstream had already passed.

Change

When left is not composed and right is a composed schema that resolveComposedSchema has already flattened (no oneOf remaining), delegate to the diff result matching left.getClass() instead of declaring a type change.

Delegating rather than calling super.diff(...) matters: SchemaDiffResult does not compare array items, so a plain fall-through would trade a false positive for a false negative. Routing through left.getClass() sends the array case to ArraySchemaDiffResult, which reads both sides via Schema#getItems() after #916.

A composed schema that still carries oneOf keeps reporting a type change — that is a genuine structural difference, not an allOf wrapper.

Tests

• Issue887Test — both directions now assert assertOpenApiAreEquals instead of only "does not throw". testDirectArrayToAllOfArrayAreEquals fails without the main-code change; the ClassCastException regression from ClassCastException when comparing schema changed from allOf to direct array type #887 stays covered, since a throw fails the equality assertion too.
• Issue920Test (new, with fixtures) — a changed item type across the same allOf/direct boundary must still be reported as incompatible. This guards the new delegation path against silently skipping items; note it does not reproduce the original bug, because the old spurious type change also rendered as incompatible.

./mvnw verify passes on all modules (core 270 tests, maven 13 tests, 0 failures).

🤖 Generated with Claude Code

---

Summary by cubic

Fixes a false breaking change when comparing a direct array schema to an allOf-wrapped array. Flattened composed schemas are now treated as plain, and the diff routes via the left-hand schema to keep item comparisons intact.

• Bug Fixes
  • When the right schema is composed but flattened (no oneOf), delegate to the diff result for the left schema class instead of reporting a type change; oneOf still triggers a type change.
  • Prevents spurious "array -> array" changes while still detecting item-type differences across direct/allOf boundaries.
  • Tests updated: Issue887 now asserts equality both ways; new Issue920 ensures item-type changes are flagged.

^{Written for commit 6efa85e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 5 files

_{Re-trigger cubic}