fix: resolve issue where multi-typed schemas are presumed to be nullable - #59

Summary

Fixes #58. When type is an array, the first item is always picked and turned into Option<X>, this should not always be the case and it should respect the other variants.

Footnote: type as an array is not valid OpenAPI spec but it is valid JSON schema, which I believe this project also aims to target and I've seen APIs use type arrays in the wild (OpenFoodFacts comes to mind).

Generated compatibility

• Generated model or method signatures: Breaking, for those depending on the incorrect generated type but not breaking for those only needing Option<X> for [X, null].
• Query/path/header/body wire behavior: Now correctly respects variants but still respects nullable array types.
• Remaining unsupported OpenAPI shapes: Disciriminated multi-type unions ( type: [string, integer with enum: [...] do not resolve with the enum for the string variant, though I've never seen this in the wild, only anyOf with the variants. Most online resources (for example https://www.learnjsonschema.com/2020-12/applicator/anyof/) also suggest the latter.

Validation

• Added or updated a focused fixture and behavioral regression test.
• Reviewed every changed snapshot; no unrelated churn is included.
• cargo fmt --check
• cargo clippy --all-features -- -D warnings
• cargo test --all-features
• Ran scripts/install-smoke.sh for packaging/dependency changes.
• Ran a targeted or full scripts/spec-compile.sh for generator changes.
• Updated README, rustdoc, or changelog for user-visible behavior.

Notes for reviewers

#58 provides a before and after.