feat: allOf / oneOf / discriminator resolution

Start with the OpenAPI schema model/parser from #1, likely under devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/openapi/, and review how #10's schema synthesis will consume it. Define and document deterministic handling for allOf, oneOf, anyOf, and discriminator mappings, then add realistic fixture tests. Done means common compositions resolve correctly and malformed or conflicting cases fail with clear errors.

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 (#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 #1's OpenAPI schema model/parser lands (likely devview-networkmock-core/src/commonMain/kotlin/com/worldline/devview/networkmock/core/openapi/)
• #10's schema-synthesis code, once it exists, will need to call into this