Fix invalid Rust emitted for defaults on types with flattened properties

[danieleades]

Problem

When generating a Rust value expression for a type-level default on a struct that has a #[serde(flatten)] property (e.g. an object with additionalProperties alongside declared properties), the code in typify-impl/src/value.rs interpolated the flattened property's name as a string literal instead of an identifier:

let name = &prop.name;
Some(quote! { #name: #flat_value })

Since name is a String, quote! renders it as a string literal ("extra": ...) rather than a field name, producing invalid Rust inside the struct literal. This causes rustfmt/compilation to fail for any generated default value on a struct with a flattened property.

Fix

Build a proper identifier for the flattened field, matching the sibling non-flattened path a few lines above (format_ident!("{}", &prop.name)).

Testing

Added typify/tests/schemas/flatten-default.json, a minimal schema with a struct-typed property carrying a default where the struct has both declared properties and additionalProperties (flattened into a map). This is picked up automatically by the existing test_schemas harness, which regenerates and rustfmts the output and then compiles it via trybuild.

• Confirmed on unpatched code this schema causes generation to fail with error: expected identifier, found "extra" (rustfmt).
• With the fix, cargo test --workspace --locked passes, including trybuild compilation of the new golden file.
• cargo fmt --all -- --check is clean.

[ahl]

yep! nice find. Did you encounter this with a real schema? If not, how did you hit this?

[ahl]

I suppose the key to the map should actually be a newtype wrapper around a String that prohibits values that conflict with existing property names (here "id")...

[danieleades]

Yes, I think that is a separate correctness gap in how we model typed additionalProperties. The generated public map lets callers insert id, which can produce a duplicate or conflicting key during serialization even though deserialization routes id to the declared field. A key newtype or custom map wrapper that excludes declared property names would make that invariant explicit.

I would keep this PR scoped to the invalid Rust emission, since it is already a complete compile fix, and track the key-collision behavior separately with construction and round-trip tests.

[danieleades]

I did not encounter this in a production schema. I found it while tracing the whole-type-default path through value_for_struct_props: the flattened branch was the one place that interpolated a String directly into quote!. I reduced that to this fixture and confirmed that the unpatched generator emits "extra": ..., which rustfmt rejects as an expected-identifier error.