fix(schema): honor single-entry patternProperties as additionalProperties

[schani]

Bug

Reported in #1643: a JSON Schema object whose value type is described with
patternProperties (rather than additionalProperties) loses all type
information when the pattern isn't the literal string .*. For example:

{
  "type": "object",
  "properties": {
    "alternators": {
      "type": "object",
      "patternProperties": {
        "(^[A-Za-z0-9]+$)": {
          "type": "object",
          "properties": {
            "voltage": { "type": "number" },
            "name": { "type": "string" }
          }
        }
      }
    }
  }
}

generated (Swift, but reproducible in every language):

let alternators: [String: JSONAny]?

with a warning that quicktype couldn't infer the type, even though the
pattern's schema fully describes the map's value type.

Root cause

packages/quicktype-core/src/input/JSONSchemaInput.ts had a narrow hack
(originally added for #976) that only treats patternProperties as a stand-in
for additionalProperties when the single pattern key is exactly ".*".
Any other pattern — including ones that are effectively "match anything" like
(^[A-Za-z0-9]+$) — was ignored entirely, so the property fell back to
untyped any.

Fix

Generalize the existing heuristic: when additionalProperties is not
explicitly set and patternProperties has exactly one entry, use that
entry's schema as the effective additionalProperties, regardless of what
the pattern text is. Schemas with multiple patternProperties entries are
left unchanged (still unsupported — out of scope here). The .* case
continues to work exactly as before.

let additionalProperties = schema.additionalProperties;
// Treat a single pattern property as additional properties since
// per-pattern typed properties aren't supported.
if (
    additionalProperties === undefined &&
    typeof schema.patternProperties === "object" &&
    schema.patternProperties !== null
) {
    const patterns = Object.getOwnPropertyNames(schema.patternProperties);
    if (patterns.length === 1) {
        additionalProperties = schema.patternProperties[patterns[0]];
    }
}

Test coverage

• test/inputs/schema/pattern-properties.schema + .1.json: new JSON Schema
  fixture reproducing the reported shape (a patternProperties entry with a
  non-.* pattern describing a map of typed sub-objects). This is
  auto-discovered by the schema-* fixtures in test/fixtures.ts.
• test/unit/pattern-properties-schema.test.ts: focused unit test asserting
  the generated Swift output contains a typed dictionary value
  ([String: Alternator]? with typed name/voltage fields) and no longer
  contains JSONAny.
• The pre-existing .*-pattern fixture
  (test/inputs/schema/go-schema-pattern-properties.schema) still passes,
  confirming no regression to that case.

Verification

• npm run build passes.
• npx vitest run test/unit/pattern-properties-schema.test.ts passes.
• QUICKTEST=true FIXTURE=schema-golang script/test — all 68 schema fixture
  tests pass, including the new pattern-properties.schema and the existing
  go-schema-pattern-properties.schema (.* case).
• Re-ran the original repro directly (node dist/index.js -l swift -s schema --src schema.json): output now shows let alternators: [String: Alternator]? with a generated Alternator struct containing typed
  name/voltage fields, and the "cannot infer this type" warning is gone.
• CI will additionally validate the fixture across all other supported
  target languages.

Fixes #1643

🤖 Generated with Claude Code

[github-actions]

Generated-output differences

26 files differ — 0 modified, 26 new, 0 deleted
2172 changed lines — +2172 / −0

Open the generated-output report →

[github-actions]

Generated-output differences

27 files differ — 0 modified, 27 new, 0 deleted
2242 changed lines — +2242 / −0

Open the generated-output report →