Why are generated API enums marked as @frozen?

### Question

**Current situation**
Currently, the openapi generator for types will convert a swagger that includes a property, e.g. `UploadStatus`, with an enum specification
```
"UploadStatus": {
"type": "string",
"enum": ["NOT_REQUIRED", "PENDING", "REQUIRED", "COMPLETED"]
},
```

to code like

```
@frozen public enum UploadStatus: String, Codable, Hashable, Sendable, CaseIterable {
case notRequired = "NOT_REQUIRED"
case pending = "PENDING"
case required = "REQUIRED"
case completed = "COMPLETED"
}
```

This generated code prevents users from providing fallback cases for the case the API will change in the future. Currently, when the server returns an enum value that is not present in the used (old) swagger specification (e.g. "AWAITING_APPROVAL"), the openapi generator treats the entire response as 'undocumented'.

**Question**
How can I best account for future API changes to the value of an enum, while making use of strongly typed Swift code as much as possible?

This question is related to https://github.com/OpenAPITools/openapi-generator/issues/1529#issue-383647757

**Considerations**
Initially I thought that nonfrozen enum annotations could be useful here, resulting in a `@unknown default:` case handling, but on second thought it seems not to be as you cannot manually instantiate the unknown enum value.

Would instead (an openapi configuration to enable) enums being optional, in case they cannot be parsed, be possible? This would however not be distinguishable from a (non-required) property missing, I expect.

Start by tracing the openapi generator's type and enum generation behavior described in this issue, then review the related discussion in issue 1529. Determine whether an implementation can preserve strongly typed Swift enums while handling values absent from the generated cases, and document a concrete configuration or parsing behavior as the definition of done.

Written by the indexing model from the issue text.