feat: allOf / oneOf / discriminator resolution

[MaxMichel2]

Part of #72

Depends on #1, #10. Not blocking for 0.2.0 — follow-up depth issue.

Summary

Resolve allOf/oneOf/anyOf composition and discriminator-based polymorphism in JSON Schemas encountered while parsing an OpenAPI spec, so that schema-driven features (#10's synthesis, any future validation-adjacent feature) work correctly against real-world specs that use these constructs — which is common, especially for polymorphic response shapes.

Current state

The core parser built in #1 is explicitly scoped to a subset of OpenAPI (see #1's "explicitly out of scope" list): allOf/oneOf/anyOf/discriminator resolution is called out there as deferred. This issue is where that deferred work actually gets scoped and built once there's a concrete need for it (most likely driven by #10's schema synthesis hitting a composed schema and not knowing what to do with it).

What to build

• allOf: merge all member schemas' properties into one effective schema.
• oneOf/anyOf without a discriminator: pick a strategy for which variant to use when synthesizing (Dependency Dashboard #10) — likely "first declared variant" is a reasonable default, since there's no runtime data to disambiguate at spec-parse time.
• oneOf with a discriminator: resolve discriminator.propertyName and discriminator.mapping to determine which variant a given example or synthesized value actually represents.

This is meaningfully more complex than the rest of the parser (#1) — JSON Schema composition has real edge cases (conflicting property definitions across allOf members, circular refs, etc.). Scope the first pass narrowly (handle the common, well-formed cases; fail loudly rather than silently misinterpreting on anything unusual) rather than attempting full JSON Schema spec conformance.

Acceptance criteria

• allOf member schemas are merged correctly for the common case (non-conflicting properties).
• oneOf/anyOf without a discriminator falls back to a documented, deterministic strategy.
• oneOf with a discriminator resolves to the correct variant given a discriminator.propertyName value.
• Malformed or unusually-structured composition (e.g. conflicting allOf members) fails with a clear error rather than silently producing a wrong result.
• Tests cover all of the above against realistic fixture schemas.

Files likely touched

• Wherever ✨ Add initial DevView #1's OpenAPI schema model/parser lands (likely devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/openapi/)
• Dependency Dashboard #10's schema-synthesis code, once it exists, will need to call into this

[github-actions]

This issue is stale because it has been open for 21 days with no activity.