Order of properties after allOf merge with $ref and oneOf does not match definition order

Describe the bug

When a combination of allOf, $ref, and oneOf is used in a heavily nested way, redoc does not maintain the order of properties as defined in the specification.

With the OpenAPI snippet below and the screenshot, assume that the composite-with-id schema is used in a requestBody for an endpoint in the main openapi.yaml spec. I would expect that the id property to be listed at the top since it's from the first schema in the outer allOf in the composite-with-id schema, but instead the properties from the types schema is being prioritized.

If I directly copy the oneOf from the types schema and inline it into the composite-with-id schema where it's referenced, then the order of properties is correct. So this appears to be an issue traversing $ref boundaries when it comes to merging allOf schemas.

Environment:

• OS: Windows 10
• Node.js: v18
• NPM: v9
• redoc-cli: 0.13.20 (in package.json)
• redoc: 2.0.0-rc.77 (in package-lock.json)
• OpenAPI 3.1

Expected behavior

Redoc should maintain the order of properties.

Minimal reproducible OpenAPI snippet

composite-with-id:
  allOf:
    - properties:
        id:
          type: number
      required: [id]
    - $ref: "#/types"
    - $ref: "#/extras"

extras:
  properties:
    other:
      type: string

types:
  oneOf:
    - $ref: "#/type-1"
    - $ref: "#/type-2"

type-1:
  type: object
  properties:
    one:
      type: string
    value:
      type: number
  required: [one]

type-2:
  type: object
  properties:
    two:
      type: string
    value:
      type: number
  required: [two]

Screenshots

Additional context

Related issue: #507

Reproduce the issue with the provided OpenAPI 3.1 snippet in Redoc 2.0.0-rc.77, focusing on the nested allOf, $ref, and oneOf traversal. Trace how referenced schemas are merged and ordered. Done means the id property appears before properties from types and extras, matching the outer allOf definition order.