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!(