close: tie LOD distance ordering exceptions - 80/1864 classes have mid=8192 far=8190

Tie class headers ordered near < mid < far on most classes. Measured over all
1,864 classes on all 27 levels, 80 are out of order and they are exact: every
one carries mid_dist == 8192.0 and far_dist == 8190.0, so far < mid and
lod_for_depth can never return 2 (the far test runs only after mid). Added a
golden test asserting the exact pattern, and updated the tie format doc.

Co-authored-by: reaper <reaper@users.noreply.github.com>

crates/gc-formats/src/tie.rs

@@ -18,12 +18,16 @@
 //! the remainder would repeat the pattern this project keeps running into: a
 //! field order that produces plausible output and is wrong.
 //!
-//! Evidence for what is decoded, over 320 classes across five levels:
+//! Evidence for what is decoded, over 1,864 classes on all 27 levels:
 //!
-//! * `o_class` at `0x44` equals the core index's class number: **320 of 320**.
+//! * `o_class` at `0x44` equals the core index's class number: **1,864 of 1,864**.
 //!   A coincidence is not a plausible explanation for that.
-//! * the LOD distances are ordered `0 < near < mid < far`: 315 of 320. The
-//!   five exceptions are not yet explained and are worth chasing.
+//! * the LOD distances are ordered `0 < near < mid < far` on most classes, but
+//!   **80 of 1,864** break it in an exact pattern: `mid_dist` is exactly
+//!   `8192.0` and `far_dist` is exactly `8190.0` in every one. Those classes
+//!   have `far < mid`, so `lod_for_depth` can never return 2 (the `far` test is
+//!   reached only after the `mid` test). Effectively two LOD tiers, not three.
+//!   See `docs/plan/level-assets.md` for the test.
 
 use crate::buf::{Buf, Error, ErrorKind, Result};
 use crate::level_core::ClassEntry;