Returning more descriptive errors for invalid enum defaults

When trying to generate a REST client crate from an OpenAPI spec, I ran into this error output from progenitor:

gen fail: TypeError(InvalidValue)
Error: generation experienced errors

After tracing the error to typify I realized the schema had some properties with invalid defaults. Here's a basic example:

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "definitions": {
        "Foo": {
            "title": "Foo",
            "type": "object",
            "properties": {
                "bar": {
                    "title": "Bar",
                    "enum": [
                        "Foo",
                        "Bar"
                    ],
                    "type": "string",
                    "default": "Baz"
                }
            },
            "additionalProperties": false
        }
    }
}

It was this match arm that ended up being the one for my case:
https://github.com/oxidecomputer/typify/blob/d36f65eea4356374a1d7e68009ecc210756ec755/typify-impl/src/defaults.rs#L151-L153

This is a slightly cleaned up version of the change that gave me enough info to find the problem with my schema file:

EnumTagType::External => validate_default_for_external_enum(
    type_space, variants, default,
)
.ok_or_else(|| Error::InvalidSchema {
    type_name: self.name().map(String::to_owned),
    reason: format!(
        "Invalid default {}, must be one of: {:?}",
        default,
        variants
            .iter()
            .map(|variant| variant.name.to_owned())
            .collect::<Vec<String>>()
    ),
}),

Ideally the error message could just be a JSON path like mentioned here: https://github.com/oxidecomputer/typify/issues/485#issuecomment-1896464088. I assume that would require a more structural refactor, but I'd be interested in pushing errors like this in the intended direction either way.

Start in typify-impl/src/defaults.rs around the EnumTagType::External match arm and trace how invalid enum defaults become TypeError(InvalidValue). Review issue #485 for the intended JSON-path direction. Done means invalid defaults produce descriptive errors that identify the invalid value and relevant enum context, with the existing generation behavior preserved.