[BUG] 3.1.0 specs generate separate nested classes for shared enum types

Description

OpenAPI 3.1.0 generates separate nested classes for shared enum types when the enum is defined in the global schema via a $ref.

The example project I've linked shows that a shared class is generated (Fruit) if the enum is not defined via a $ref, but generates nested enum classes if the enum is defined via a $ref (Vegetable).

The difference can be seen here in the definitions of the /generateFruitPallet and /generateVegetablePallet endpoints: https://github.com/shorn/openapi-fruitbat/blob/main/shared-enum-3.1/src/main/openapi/shared-enum.yaml

The only structural difference between those two endpoints is defining the enum via a $ref.

You can also see in this project that if the 3.0.3 spec is used, shared enum classes are generate regardless of whether the enum is defined via a $ref.

openapi-generator version

7.0.1
As per https://github.com/shorn/openapi-fruitbat/blob/4cd5a6125d8f2a5039d4fa3fd04ac7936eef04f6/shared-enum-3.1/build.gradle#L15

The example project shows that the enum class are correctly generated when using openapi verison 3.0.3 (but still same generator version 7.0.1)

OpenAPI declaration file content or url

OpenApi 3.1.0: https://github.com/shorn/openapi-fruitbat/blob/main/shared-enum-3.1/src/main/openapi/shared-enum.yaml
OpenAPI 3.0.3: https://github.com/shorn/openapi-fruitbat/blob/main/shared-enum-3.0/src/main/openapi/shared-enum.yaml

Generation Details

Example github project: https://github.com/shorn/openapi-fruitbat

Steps to reproduce

Execute the :shared-enum-3.0:generateSpringServerInterface and :shared-enum-3.0:generateSpringServerInterface.

Then inspect the generated java code in each project's build/generated/spring directory. You will see that the 3.0.3 spec generates a shared class for the Vegetable type. But the 3.1.0 spec generates nested enums that are not assignment compatible.

You can also see the problem is present with other generator types by executing the generateTypescriptClient tasks.

Related issues/PRs

None that I could find.

Suggest a fix

I don't see how; but if it is decided that this behavior is "working as intended" - consider adding explicit documentation of that because it's going to cause people a lot of issues (especially for Java projects).

Start with the linked openapi-fruitbat example and its shared-enum.yaml files, then run the listed Gradle generation tasks and compare the generated Java and TypeScript output. Trace the generator path that handles global enums through $ref. Done means shared enum types remain assignment-compatible rather than becoming separate nested classes for the OpenAPI 3.1.0 case.