Dataset validation does not check the registry, release and schema field types the application deserializes

Crate: ephervex-options (generated data) and tools/minecraft-options

Commit: f844b107

Behavior

validate() documents that it refuses exactly what the application's loader refuses. It now checks codecs, keys, representation positions, the unsupported lists, revision and data_version, but not the other field types crates/options/src/dataset.rs requires through serde:

• RegistrySetting.key and type must be strings, category and translation_key optional strings, manageable a bool;
• canonical_minecraft_version, ReleaseMapping.minecraft_version, ReleaseMapping.schema and SchemaFamily.id must be strings;
• SchemaFamily.supported must be a string-keyed object.

A hand-edited or corrupted previous dataset with manageable: null or a numeric category passes validate() and is published, then refused wholesale by the application as malformed. A non-object schema, release or registry entry, or a non-hashable schema id, makes validate() raise TypeError, KeyError or AttributeError instead of DatasetError, which update.py main does not catch.

Expected behavior

validate() refuses these shapes with DatasetError.

Impact

A dataset the application cannot load can still pass the publication gate, and clients silently keep their old data.

Locations

• tools/minecraft-options/dataset.py validate
• crates/options/src/dataset.rs (serde field types)

Validation and limitations

Read from the current validate(); schema["supported"].items() and release["schema"] not in families are reached without a type check. Follows #601, whose fix covers codecs, keys, positions and the unsupported lists but not these field types.