Docs audit: 15 stale figures left behind by two fixes, including a wrong numerator

Checked the docs for claims this session retracted. Found more than the first pass.

    1,163 -> 1,162   9 in the format spec, 3 in the roadmap, 5 test doc-comments
    5,878 -> 5,822   2 in the spec, 3 in test doc-comments
    234 -> 233       1 in the spec, 1 test doc-comment -- level 0's contribution

The last one is the one a blanket search would have missed. "5,878 records, and
level 0 contributes 234" was stale in both numbers, and only one of them was in
the string I was looking for. Verified against the tests rather than against the
other stale prose:

    lvl.vtbl: 1162 distinct class ids from 5822 records; max 0x13ba (5050);
    moby_classes.count is 238, and 1135 of 1162 ids (97.7%) are at or above it
    vtbl oClass: 1162 ids, largest 5050; ... 1133/1162 ... level 0 alone
    contributes 233

The reason all of it survived is the same shape as the bug it belongs to. The
tests were fixed and the new numbers asserted, and the prose was not touched -- and
the prose is what a reader takes away. A commit that corrects a measurement without
correcting the document it was measured in has only half-landed. Two corrections in
this session, 15 places.

Also left alone deliberately: the explanatory sections in core-data-regions.md that
discuss 5,878 and 1,163 as the *wrong* figures, and the test comments that record
what the loop used to print. Those are correct as written -- removing them would
erase the reasoning. A final sweep confirms nothing stale remains outside those.

293 passing with the disc and savestate present, clippy clean. Documentation and
comments only; no behaviour changed.

crates/gc-extract/tests/disc.rs

@@ -6520,10 +6520,10 @@ fn overlay_bin_is_the_seven_section_program_not_the_lit_section() {
 ///
 /// `lvl.vtbl` is section 3 of the level program: records of `{oClass, handler,
 /// auxiliary pointer}`, three words each, ending on padding. Across the 27
-/// levels that is **1,163 distinct class ids**, ranging to `0x13BA` (5,050),
+/// levels that is **1,162 distinct class ids**, ranging to `0x13BA` (5,050),
 /// with a median of 38 new ids contributed per level.
 ///
-/// `LevelCoreHeader::moby_classes.count` is 238 on level 0. **1,135 of the 1,163
+/// `LevelCoreHeader::moby_classes.count` is 238 on level 0. **1,135 of the 1,162
 /// ids -- 98% -- are at or above that number.** So a test that treats
 /// "value < moby_classes.count" as "this looks like a class id" is really testing
 /// "is this a small number".
@@ -6535,7 +6535,7 @@ fn overlay_bin_is_the_seven_section_program_not_the_lit_section() {
 /// of it.
 ///
 /// Re-scored against the real id set, no chunk slot stands out: the best is 0.375
-/// against a chance rate of 0.018 (1,163 ids in 65,536 values), and a dozen slots
+/// against a chance rate of 0.018 (1,162 ids in 65,536 values), and a dozen slots
 /// sit between 0.25 and 0.38 with no separation between them.
 #[test]
 fn moby_class_ids_come_from_lvl_vtbl_not_from_the_class_count() {
@@ -6623,13 +6623,13 @@ fn moby_class_ids_come_from_lvl_vtbl_not_from_the_class_count() {
 /// the level's class table.
 ///
 /// The two are easy to conflate and are not the same axis. Across the 27 levels
-/// the vtbl carries 1,163 distinct identifiers reaching **5,050**, while
+/// the vtbl carries 1,162 distinct identifiers reaching **5,050**, while
 /// `moby_classes.count` runs 161 to 259 per level. So `oClass` cannot index the
 /// class table -- almost every identifier would fall off the end.
 ///
 /// The identifiers are *shared* rather than per-level: the set is cumulative
-/// across the 27 levels and no level re-uses the numbering, so 1,163 distinct
-/// identifiers come out of 5,878 records. Level 0 contributes 234 and levels 1-8
+/// across the 27 levels and no level re-uses the numbering, so 1,162 distinct
+/// identifiers come out of 5,822 records. Level 0 contributes 233 and levels 1-8
 /// contribute 72, 69, 77, 54, 41, 68 and 28 -- roughly each level's own share,
 /// not a single level dominating.
 ///
@@ -6718,7 +6718,7 @@ fn vtbl_class_ids_are_global_and_do_not_index_the_class_table() {
         out_of_range * 10 >= ids.len() * 9,
         "most ids should be out of range for any per-level table"
     );
-    // and it is shared, not per-level: 1,163 identifiers come out of 5,878
+    // and it is shared, not per-level: 1,162 identifiers come out of 5,822
     // records, so levels re-use ids rather than renumbering. No single level
     // dominates -- level 0's 234 is about a fifth of the total.
     assert!(

docs/formats/core-data-regions.md

@@ -3247,7 +3247,7 @@ Phase 3 port made visible. Its records are three words:
 
 Walking all 27 levels:
 
-    5,878 records
+    5,822 records
     1,162 distinct class ids
     range 0 .. 0x13BA (5,050)
     median 38 new ids contributed per level
@@ -3306,7 +3306,7 @@ off the end. They are different axes: the vtbl names a *type* of moby, the class
 table lists the *models* a level instantiates.
 
 The identifier space is shared rather than renumbered per level: 1,162 distinct
-values come out of 5,878 records, and level 0 contributes 234 while levels 1-8
+values come out of 5,822 records, and level 0 contributes 233 while levels 1-8
 contribute 72, 69, 77, 54, 41, 68 and 28 -- each level roughly its own share, not
 one level dominating. An earlier note here said "most of the game's classes appear
 in the first level"; the data says 20%, and the assertion is written to fail if

docs/roadmap.md

@@ -442,10 +442,10 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       entries in the same overlay's `.text`, which is now readable. Asserted.
 - [x] `lvl.vtbl`'s **`oClass` is a global identifier**, not an index into the level's
       class table: 1,162 distinct ids across the game, largest 5,050, against
-      `moby_classes.count` of 136..259. **1,133 of 1,163 are out of range** for any
+      `moby_classes.count` of 136..259. **1,133 of 1,162 are out of range** for any
       per-level table. The two are different axes -- a type id, and the models a
       level instantiates -- and the space is shared rather than renumbered
-      (1,163 distinct out of 5,878 records; level 0 supplies 20%, not a
+      (1,162 distinct out of 5,822 records; level 0 supplies 20%, not a
       majority). A class can now be recognised across levels by id. Asserted.
 - [x] The **moby instance is named**: `MobyInstance`, 256 bytes, 67 fields,
       transcribed from the decomp's `include/structs.h` into `gc_formats::moby`