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.

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`