fix: external schema resolution in OAS 3.1 files

[dennisameling]

Description

When parsing OpenAPI 3.1 specifications with external schema references (e.g., $ref: "./schemas/health.yaml"), the parser resolves the schemas correctly but does not add them to components.schemas. This causes openAPI.getComponents().getSchemas() to return null (as reported in #2266), breaking downstream tooling like code generators that rely on component schemas being populated.

This works correctly for OpenAPI 3.0 specs (via SchemaProcessor/ExternalRefProcessor) but was missing in the OpenAPI 3.1 code path (OpenAPI31Traverser).

OpenAPI31Traverser.traverseSchema() handles local refs (starting with #) by adding them to components.schemas, but has no equivalent logic for external refs. External schemas are resolved and inlined during traversal, but never registered as components.

Updated behavior for setResolve(true)

Before: External schemas were resolved and inlined directly at the usage site. components.schemas was not populated with external schemas.

After: External schemas are added to components.schemas and replaced with local $refs (e.g., $ref: "#/components/schemas/ex"). The schema content now lives in components instead of being inlined.

Fixed behavior for setResolveFully(true)

Before: External schemas were resolved and inlined. components.schemas was not populated.

After: External schemas are added to components.schemas and still inlined at usage sites (because ResolverFully expands all remaining $refs afterward).

Fixes: #2266

Type of Change

• 🐛 Bug fix
• ✨ New feature
• ♻️ Refactor (non-breaking change)
• 🧪 Tests
• 📝 Documentation
• 🧹 Chore (build or tooling)

Checklist

• I have added/updated tests as needed
• I have added/updated documentation where applicable
• The PR title is descriptive
• The code builds and passes tests locally
• I have linked related issues (if any)

Screenshots / Additional Context