Make the tie record relocation a command, and verify it on two levels

The relocation rule from the previous commit was established by a script that
lived in a shell history, which means the next person would have had to
rediscover it. It is now `gc-trace verify-tie-records <unpacked-dir> <level>
<class> <lod> <src>`: resolve the class, parse the block, search the RAM image
for the loaded record table, report what it found, and exit 0 only when every
record's pointer has become table + word and every field byte is verbatim.

Swept over every (class, lod) slot of two levels, from PCSX2 savestates:

  level 0: 87 slots with a block, 87 verified, 0 mismatched, 61 absent
  level 1: 104 slots with a block, 104 verified, 0 mismatched, 78 absent

So the rule holds on every LOD block of two levels the game had loaded, which
is what makes the record layout a finding rather than a reading of one block.

Writing the command also caught an off-by-one in the parser it exercises:
TieBlockHeader::records started its slice after the 16-byte header, but the
header IS the first record -- the table runs from the block start to
data_offset, and a block with data_offset 0x50 holds five records, the first
being the header itself and its pointer naming where the payload begins. Found
because the tool's first run relocated nothing while the same check in a script
had passed; the unit test fixture was wrong in the same way and is fixed.

Two operational notes now in the format doc: the live emulator is not a stable
input (verifying level 1 over PINE matched 104 of 104 while the user was on
that planet, and the same command minutes later found no matching copy because
they had returned to level 0 -- a miss there is not a counterexample, so the
report says "no copy matched" rather than "failed"), and a class index past the
table count is an error rather than a mismatch, so a sweep should stop at the
level's class count rather than a round number.

docs/formats/core-data-regions.md

@@ -1229,6 +1229,34 @@ payload starts. A count of what follows a pointer is not the pointer.
 `TieBlockHeader::data_offset` and `TieBlockHeader::records` carry it, bound by
 the offset, and the disc test asserts the table is bounded on every block.
 
+### It is now a command, and it verifies two levels
+
+The check above was a script; it is now `gc-trace verify-tie-records
+<unpacked-dir> <level> <class> <lod> <src>`, which resolves the class, parses
+the block, searches the RAM image for the loaded record table and reports what
+it found. Exit status is 0 when every record relocated with verbatim fields.
+
+Run over every (class, lod) slot of two levels, from PCSX2 savestates:
+
+| level | slots with a block | verified | mismatched | absent |
+|---|---|---|---|---|
+| 0 | 87 | **87** | 0 | 61 |
+| 1 | 104 | **104** | 0 | 78 |
+
+So the relocation rule holds on **every** LOD block of two levels that the game
+had loaded. Two operational notes worth keeping:
+
+- **The live emulator is not a stable input.** Verifying level 1 over PINE
+  matched 104 of 104 while the user was on that planet; the same command
+  minutes later, after they had returned to level 0, found the tables in RAM
+  but no matching copy -- because the level was no longer loaded. A miss there
+  is not a counterexample, and the report says "no copy matched" rather than
+  "failed".
+- **A class index past the table count is an error**, not a mismatch, so a
+  sweep should stop at the level's class count rather than at a round number.
+
+What the records' fields name and what the payload holds are still open.
+
 ### What the payload is, and what retired the coordinate reading
 
 The payload is **not random**, and that took a control to establish. Reading each