[BUG] Upgrading to 3.1 breaks sharing types between APIs

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

When updating a specs from OpenAPI 3.0 to OpenAPI 3.1, types cannot be shared anymore, as two unrelated types are generated.

openapi-generator version

7.11.0

Steps to reproduce

Given these files:

foo.yaml

openapi: 3.0.4
info:
  title: foo API
  version: 0.0.1
paths:
  /foo:
    get:
      responses:
        200:
          description: foo
          content:
            application/json:
              schema:
                $ref: 'user.yml#/Response'

bar.yaml

openapi: 3.0.4
info:
  title: bar API
  version: 0.0.1
paths:
  /bar:
    get:
      responses:
        200:
          description: bar
          content:
            application/json:
              schema:
                $ref: 'user.yml#/Response'

and the shared common.yaml

Response:
  properties:
    id:
      type: integer

Running this will generate two files, one being the shared class:

for f in foo.yaml bar.yaml; do openapi-generator generate -g java -i $f; done

tree src/main/java/org/openapitools/client/model
src/main/java/org/openapitools/client/model
├── AbstractOpenApiSchema.java
└── Response.java

But if you change these files to openapi: 3.1.0, each API will have its own class:

src/main/java/org/openapitools/client/model
├── AbstractOpenApiSchema.java
├── BarGet200Response.java
└── FooGet200Response.java

This will make re-using code very hard. What is the recommended way to share types (classes) between APIs?

Start by running the openapi-generator generate -g java -i command with foo.yaml and bar.yaml, comparing the OpenAPI 3.0 and 3.1 inputs and their shared common.yaml reference. Inspect the generated model paths and the handling of Response, BarGet200Response, and FooGet200Response; done means determining why the shared type diverges and documenting or restoring the expected reuse behavior.