OpenAPI 3.1 validation rejects nullable keyword in schema object

Assumes an OpenAPI 3.0 source document that uses nullable: true on schema objects and must migrate to OpenAPI 3.1 while preserving runtime validation semantics.

OpenAPI 3.1 removes nullable and represents nullability through JSON Schema 2020-12 type arrays containing "null". Strict validators may reject nullable as an unknown keyword; lenient validators may ignore it. The specification does not define how nullability composes with allOf, oneOf, or anyOf, and discriminator provides no rule for nullable composed schemas.

Simple conversion from type: string plus nullable: true to type: ["string", "null"] is clear, but polymorphic validation and generated client nullability remain ambiguous across tooling.

What is the correct 3.1 translation for nullable: true inside composed schemas? Does nullability propagate differently through allOf, oneOf, and anyOf between validators? How should discriminator behave when a composed schema permits null?