fix(generator): keep the literals of a nullable enum, type empty lists

[nadar]

Problem

A select field's value is a nullable enum, and the schema lists null among its members. That is correct OpenAPI 3.0.3: nullable: true alone does not allow null unless the enum lists it.

TypeMapper::literalUnion() drops an enum it thinks is unsafe, and its check is !is_scalar($value). Since is_scalar(null) is false, a single null member threw away the whole enum, so the generated type fell back to plain string:

size: object{
    value: string|null,                    // enum ["small", "medium", "large", null]
    options: \stdClass|array<int, mixed>,
    label: string|null
}|null,

Change

• Nullable enums: a null member no longer disqualifies the enum. It becomes a trailing null, the same position the rest of the generator puts it in. enum: [null] maps to null, and arrays or objects inside an enum still fall back to string as before.
• Empty lists: an array schema with maxItems: 0 can only ever be empty, so it maps to array{}. That makes options (a map of value => label, or [] when nothing is selected) \stdClass|array{}.

size: object{
    value: 'small'|'medium'|'large'|null,
    options: \stdClass|array{},
    label: string|null
}|null,

Tests

• TypeMapperTest: nullable enum, null listed first, enum of only null, enum with an object member, maxItems: 0, a positive maxItems, the map-or-empty-list oneOf, and no double |null.
• types/site fixture: category now has the real select-field shape (null in the enum, oneOf options). Its match assertion only stays exhaustive because of the fix.
• blocks/full fixture: new nullable_enum and empty_list fields with PHPStan assertions.
• TypesAccessPatternTest: at runtime, a selected option's options is a \stdClass, and an unselected one decodes to [].
• Checked in reverse too: with the TypeMapper change reverted, 10 PHPUnit cases and 4 level-9 PHPStan assertions fail.

Worth a look

• The deprecated flyo-generate-blocks output changes too. Profile promises byte-identical output for it. I applied the fix to both commands anyway: holding it back would keep the bug there, would need a flag passed through Kind::plan(), and would break the "a block class is the same under both commands" invariant that GoldenTest checks. UPGRADE.md gets a "From 3.6 to 3.7" note saying --check reports drift until the first regeneration. Adjust the version heading if the next release is numbered differently.
• Separate commit: PHPStan repair for main. The regeneration from spec 2.49 (9d53bb5) made Block::getSlots() non-nullable. Since then the phpstan job on main fails on getSlots() ?? [] in two fixture assertions. The first commit removes the ?? [] so this PR (and main, once merged) is green again.

Verification

• vendor/bin/phpunit: 298 tests OK
• phpstan.neon, phpstan-generator.neon, phpstan-generated.neon: no errors
• Both CLI --check smoke tests from the workflow pass

🤖 Generated with Claude Code

https://claude.ai/code/session_01UGTdQLpEoYyXhbJV1znWEW

---

Generated by Claude Code