Option instance and default analysis has several unguarded edge cases

Crate: tools/minecraft-options

Commit: 2b2af1e4f8166d02e4732d19e040a53745d97a51

Behavior

Latent defects in the OptionInstance and default handling; none changes current data.

• classify_value_set returns {"kind": "int_range"} with no min/max (a text match), and analyse_option_window then reads value_set["min"] and raises KeyError. double_range defaults to 0.0..1.0 with domain_confidence: high. OptionInstance$IntRangeBase and SliderableEnum are classified unit_double.
• Every Codec.xmap that is not arithmetic (xmap(Enum::byId, Enum::getId)) sets xmap_unresolved, so ao, attackIndicator, narrator, particles, graphicsMode, chatVisibility, and prioritizeChunkUpdates carry "persisted codec transforms the value through an xmap this analyzer could not read". With several xmaps in one window the value comes from the last resolved one while unresolved stays set.
• apply_ops returns a float for every field, so the JVM-default candidate for I/J fields is 0.0, and it returns early on a division by zero without applying the remaining operations. Unknown ops are ignored.
• ephervex_manageable is true for type == "unknown" that is not a SPECIAL key, and type_confidence becomes high when a SPECIAL key's unknown type is rewritten to special.
• default has no unit marker. Legacy and field-access records store file-space values (fov 0.0 for 1.12.2 to 1.18.2), while OptionInstance records store UI-space values (fov 70), both high.

Expected behavior

Unresolved structure is reported as unresolved with correct confidence, missing bounds do not raise, and a default declares its value space.

Impact

A future numeric xmap would be indistinguishable from the current enum noise, and a consumer comparing defaults across releases misreads fov.

Locations

• tools/minecraft-options/analyze_options.py classify_value_set (1133-1143), analyse_option_window (1265-1271, 1393-1435), apply_ops (1580-1594), build_setting (2154)

Validation and limitations

Reproduced with synthetic windows and the cached fov records for 1.18.2 and 1.19.1. The KeyError was not triggered by any cached JAR.