fix: honor sibling nullable:true on single-element allOf/oneOf/anyOf

[CallMeSH]

Problem

OpenAPI 3.0 expresses a nullable composed type with a nullable: true sibling next to a single-element allOf / oneOf / anyOf:

field:
  nullable: true
  type: object
  allOf:
    - $ref: '#/components/schemas/Foo'

swagger_parser generates this field as non-nullable (Foo instead of Foo?).

The equivalent OpenAPI 3.1 form already works:

field:
  oneOf:
    - $ref: '#/components/schemas/Foo'
    - type: null

Root cause

In _findType (open_api_parser.dart), the allOf/oneOf/anyOf branch splits on element count:

• Multi-element (oneOf: [{$ref}, {type: null}]): the {type: null} member is detected and makeNullable is applied. This branch also already honors a sibling nullable: true.
• Single-element (allOf: [{$ref}]): it returns the inner ref type verbatim. The inner ref's own nullable is false, and the final nullability resolution (ofType?.nullable ?? map[nullable] ?? …) short-circuits on that non-null false, so the outer nullable: true is never consulted.

Same intent, different element count, different code path — which is why the 3.1 two-element form works but the 3.0 single-element sibling form does not.

Fix

Apply makeNullable in the single-element branch when the outer schema carries nullable: true, mirroring what the multi-element branch already does.

Tests

Adds an e2e regression test xof/nullable_sibling_all_of.3.0 covering both the 3.0 single-element sibling form and the 3.1 oneOf + type: null form. Also updates the existing all_of.3.0 expected output, whose getUserById response is {nullable: true, allOf: [{$ref: UserDto}]} and had silently captured the same bug — now correctly Future<UserDto?>. Full suite passes; dart format and dart analyze clean.