Generator: support OpenAPI 3.1 specs

The generator is OpenAPI 3.0-only today. All four specs in
packages/mittwald/spec declare openapi: 3.0.0, the validator is constructed
with version: 3, the code model is typed against OpenAPIV3, and
swagger2openapi converts 2.0 input to 3.0. Moving to 3.1 is a self-contained
piece of work that also unblocks a decision we deferred elsewhere.

Follow-up for #166 / #297. Marking a property whose type is a named schema
as deprecated —

lastMessageAt:
  $ref: "#/components/schemas/DateTime"
  deprecated: true

— is invalid in 3.0: a Reference Object "cannot be extended with additional
properties and any properties added SHALL be ignored", and the 3.0 metaschema
rejects the document. We decided in #297 not to work around this in our copy of
the metaschema, precisely because the workaround would have to be removed again
once we are on 3.1, where $ref siblings are legal on their own. So this issue
is the prerequisite for the remaining part of #166.

Precondition

The specs are fetched from api.mittwald.de / developer.mittwald.de
(build:fetch-openapi-*). The upstream API has to emit 3.1 before this becomes
useful — that is a backend decision, and this issue is likely blocked on it.
The generator side can be prepared independently, as long as 3.0 documents keep
working (version detection on the openapi field).

Work items

• Validation. openapi-schema-validator ships no 3.1 metaschema in any
  released version — 12.1.3 is the latest and bundles only openapi-2.0.json
  and openapi-3.0.json. Needs a replacement, e.g. ajv (2020-12) against the
  official OAS 3.1 metaschema, @readme/openapi-parser, or
  @apidevtools/swagger-parser; all three need evaluating. Whatever we pick
  must keep rejecting unknown keys where 3.1 still forbids them (Operation
  Object and friends) — see the negative-control test in
  packages/generator/src/openapi/OpenApiSpec.test.ts.
• Types. 21 files under packages/generator/src reference OpenAPIV3.*
  (Document, SchemaObject, ReferenceObject, OperationObject,
  PathItemObject, PathsObject, ComponentsObject, ResponseObject,
  ResponsesObject, MediaTypeObject, TagObject, HttpMethods,
  ApiKeySecurityScheme, HttpSecurityScheme). openapi-types provides
  OpenAPIV3_1; decide between a union type and a version branch.
• Schema dialect. 3.1 Schema Objects are JSON Schema 2020-12, while
  json-schema-to-typescript@15 targets draft-07. Check prefixItems, const,
  $defs, numeric exclusiveMinimum/exclusiveMaximum, and examples.
• nullable is gone in 3.1, replaced by type: ["string", "null"]. The
  committed specs use it 59× (v2) and 58× (v3-next), so this is the largest
  behavioural surface: the generator has to understand the new form and the
  emitted TypeScript must stay string | null.
• $ref siblings. summary/description on a Reference Object
  override the target's; annotations next to a Schema Object $ref apply
  normally. generation/refs/componentRefsToCustomTypes.ts already preserves a
  deprecated sibling, but only because our own model puts it there — that
  needs revisiting once siblings can legitimately come from the input.
• 2.0 input. Decide whether swagger2openapi keeps converting to 3.0
  and we accept both, or whether 2.0 gets a second hop.
• Regenerate both clients and review the diff; expect changes wherever
  nullable was used.

Non-goal

Nothing here should change behaviour for 3.0 documents. Accepting 3.1 is
additive; 3.0 stays supported.

Start with packages/generator/src/openapi/OpenApiSpec.test.ts, the 21 generator files referencing OpenAPIV3, and generation/refs/componentRefsToCustomTypes.ts. Evaluate the listed 3.1 validation options, then trace nullable and $ref handling before regenerating both clients; done means 3.1 is accepted while 3.0 behavior and unknown-key rejection remain intact.