Correct the chunk loader finding and decode a record field

The loader note said every record gains a 02 00 prefix in RAM. It does not:
the word is the record's own leading field, already on the disc at every
record. What the loader changes is the pointer -- it addresses the word, two
bytes earlier than the disc's table -- and that pointer shift is what made the
bytes look inserted.

Measured, in order:

- the two bytes before a payload are identical in core_data and in RAM, record
  for record: 02 00 on level 0's 90-record chunk at 0x100b302, 08 00 on the
  level's first chunk. Nothing is inserted;
- the RAM table's low 24 bits are the payload's minus 2, consistently, so the
  record is [leading u16][two index bytes][payload] and the loaded table
  addresses the leading word. That is also why the index bytes read as +2 from
  the pointer -- the same +2 the earlier RAM result quotes;
- the word is a field, not a pad: uniform across a chunk's records on 1,439 of
  1,509 chunks (None on the 70 that vary, reported rather than averaged),
  fixed within all 71 chunk types, and only ever 1, 2, 4, 6, 8 or 10 -- 554
  chunks carry 2, 520 carry 4.

Two readings of the value were measured and disproved, so they are recorded as
disproved rather than left as candidates: it is not an entry count (the payload
divided by it leaves 57 distinct fractional "sizes", and 162 chunks do not
divide at all), and it is not the number of distinct leading bytes (agrees on 0
of 1,506 chunks).

Chunk gains `prefix: Option<u16>`, and the disc test asserts the uniformity,
the per-type fixity and the value set. The scratch example that produced the
per-type class-ID table is dropped now that the same scan is a committed test,
which also lands here: moby class IDs sit in one body slot per chunk type, with
the slot varying by type and the distinct >= 4 filter load-bearing -- without it
the top slots are constants that read as 305x because any value below the moby
count counts as a hit.

docs/formats/core-data-regions.md

@@ -1451,3 +1451,40 @@ The third result is the useful one: the byte at `+2` takes exactly
 `0, 16, 32, ... 240` -- the 16 values `index_rule` predicts for `step = 16,
 phase = 0`. The mixed-radix record index, derived from the disc, is corroborated
 on the running game's own copy.
+
+### Correction: the `02 00` is on the disc, and a record starts two bytes earlier
+
+What the loader does to the *pointer* is as described above. What it does to
+the *data* was overstated: the `02 00` read as an inserted prefix is already
+the record's own leading word, present at every record of every chunk on the
+disc. Three measurements, in order:
+
+- **The 2 bytes before the payload are on disc.** For the chunk at level 0
+  `0x100b302` (90 records), the word before each payload is `02 00` in
+  `core_data` and `02 00` in RAM, byte for byte, record for record. The first
+  chunk of the same level carries `08 00` instead. Nothing was inserted.
+- **So the RAM table's pointer is simply two bytes earlier.** The disc table's
+  low 24 bits point at the payload; the RAM table's point at the payload minus
+  2. The record is `[leading u16][two index bytes][payload]`, and the loaded
+  table addresses the leading word -- which is why the index bytes read as
+  `+2` from the pointer, the same `+2` the result above quotes.
+- **The leading word is a field, not a prefix.** It is the same at every
+  record of a chunk on **1,439 of 1,509 chunks** (`None` on the 70 whose
+  records disagree, which the parser reports rather than averaging), it is
+  fixed within **every one of the 71 chunk types**, and its values are only
+  `1, 2, 4, 6, 8, 10` -- 554 chunks carry 2, 520 carry 4. `Chunk::prefix`
+  carries it.
+
+What the value counts is not established, and two readings were measured and
+disproved rather than left as guesses:
+
+- **Not an entry count.** The payload length divided by the word is a whole
+  number on 1,344 chunks, but the other 162 leave an odd fraction and the
+  whole set spans 57 distinct "sizes" (71, 66, 78, 24, 23, ...). A real entry
+  size is a small clean number, not a set like that.
+- **Not the number of distinct leading bytes.** That agrees on 0 of 1,506
+  chunks.
+
+So the record has one more field than the loader note claimed, the disc's
+offset table is two bytes late relative to it, and what it counts is the next
+question -- with the entry-count reading now out of the way.