fix: preserve multi-type type union when schema has subschemas (#954)

[ndreno]

Fixes #954.

Problem

When a schema has both a multi-type type: [...] and a sibling oneOf / anyOf / allOf / not on the same object, convert_schema_object matches an arm that wildcards instance_type (flagged by a pre-existing // TODO we probably shouldn't ignore this...). The subschema branches are then converted in isolation, silently discarding the outer type union.

For the schema from the issue thread:

{
  "type": ["string", "number", "boolean", "array"],
  "oneOf": [
    { "items": { "type": "string" } },
    { "items": { "type": "number" } },
    { "items": { "type": "boolean" } }
  ]
}

typify emitted only three array variants, dropping string / number / boolean entirely:

pub enum FooValue {
    Variant0(Vec<String>),
    Variant1(Vec<f64>),
    Variant2(Vec<bool>),
}

Fix

Tighten the earlier match arm from instance_type: _ to instance_type: None | Some(SingleOrVec::Single(_)). Schemas with Some(Vec(_)) fall through to the existing "Subschemas with other stuff" arm below, which already folds the outer schema into each subschema branch via try_merge_with_subschemas. Behaviour for None / Single is unchanged, so the existing tolerant handling of schemas whose outer singleton type conflicts with a branch (e.g. the rust-collisions fixture) is preserved.

After the fix, the issue's schema expands to:

pub enum FooValue {
    Variant0(FooValueVariant0),
    Variant1(FooValueVariant1),
    Variant2(FooValueVariant2),
}
pub enum FooValueVariant0 {
    Boolean(bool),
    Number(f64),
    String(String),
    Array(Vec<String>),
}
// Variant1 carries Array(Vec<f64>); Variant2 carries Array(Vec<bool>).

This is not the exact factored shape discussed in the issue thread (hoisting the shared primitive alternatives above a single Array variant whose inner type is itself an enum). Reaching that would require an additional dedup/factoring pass across the oneOf branches. This PR restores structural accuracy: every alternative from the outer type union is represented, and the items constraint is applied to the Array variant of each branch.

Tests

No existing fixture exercised type: [...] alongside subschemas on the same object, so the bug had zero regression coverage. Adds typify/tests/schemas/type-array-with-subschemas.json with eight cases:

• type:[...] with oneOf / items-only branches (canonical Panic: Not yet implemented: unhandled not schema Object #954 case)
• type:[...] with anyOf
• type:[...] with allOf (constraint refinement, including a numeric minLength that manifests as a newtype wrapper)
• type:[...] with not (type exclusion)
• Singleton type + conflicting oneOf branch (regression guard for the rust-collisions pattern)
• type:[...] with oneOf where every branch pins type: array (primitives correctly pruned)
• type:[...] with oneOf where some branches are unsatisfiable against the outer type union
• type:[...] with oneOf fully unsatisfiable (emits empty enum via convert_never, no panic)
• type:[...] with simultaneous oneOf and allOf

The generated fixture compiles under #![deny(warnings)] via trybuild. Full workspace cargo test is green.

Out of scope

The top-level anonymous-enum panic at type_entry.rs:306 (get_type_name(...).unwrap()) still trips for schemas whose subschema-with-type-union construct sits directly at the root. Wrapping the construct in $defs is sufficient today. That panic is a separate issue and not addressed here.