[feature]: Support OpenAPI Overlay 1.1

[adriendellagaspera]

Use case

schema_extensions supports additive JSON/YAML deep merges, but cannot express the full OpenAPI Overlay 1.1 semantics: targeted removals, JSONPath-based updates, copies and ordered transformations.

Supporting the standard would let users keep reproducible modifications separate from the source OpenAPI document without maintaining a complete fork.

Area

CLI and configuration

Representative OpenAPI fragment

openapi: 3.1.0
info:
  title: Example API
  version: 1.0.0
paths:
  /legacy:
    get:
      operationId: getLegacy
      responses:
        "204":
          description: No content

Desired generated API or behavior

Allow configuration to reference OpenAPI Overlay 1.1 files, applied sequentially before analysis and generation.

Support update, copy and remove using RFC 9535 JSONPath. Resolve overlay paths relative to the configuration file.

Allow optional deterministic materialization of the effective OpenAPI document. That document must be the same input used for Rust generation. Materialized output should follow the existing --check and --dry-run semantics.

Keep schema_extensions available and document the application order when both mechanisms are configured.

Alternatives considered

schema_extensions is useful for additive deep merges, but cannot express removals or the full Overlay operation set.

Maintaining a complete modified OpenAPI document makes upstream updates harder to incorporate.

External preprocessing works, but adds another tool and requires users to coordinate its output with generation and --check.

Compatibility

• I considered whether this changes existing generated Rust APIs or wire behavior.
• I searched existing issues and discussions for this request.