Assert the tie vertex layout finding in a test, and audit which claims are asserted

The i16[3] high-byte finding -- the most recent and most subtle result of this
stretch, and the one I corrected twice -- lived only in prose. Two commits is
exactly how long a claim can sit unasserted before it drifts. It now has a test:

  tie_vertex_layout_is_selected_by_i16_3_high_byte

which reproduces the figures exactly and, importantly, asserts both directions:
(4,5) and (6,7) are above 0.85 and 0.80 in the ordinary group, (6,7) is BELOW 0.99
so it cannot silently become the constant I once mistook it for, (0,1) and (2,3)
are under 0.20, and every pair in the non-zero group is under 0.15. A future
change in either layout now fails loudly.

Also audited the rest of this session's claims against the test suite and recorded
the result in the format doc:

  tie vertex element is 16 bytes             asserted
  layout selected by i16[3] HIGH byte       asserted (this commit)
  blocks self-delimiting on 0xf6            asserted per-block
  packets == 0 means no block at that LOD   asserted
  packets[0] == 256 on 1,864 of 1,864       asserted
  chunk record length uniform per chunk      asserted
  moby class IDs in one body slot per type  asserted

  collision payload verbatim in RAM         NOT assertable here -- needs a savestate
  tfrag patch bytes all rewritten by LOD    same
  morphing is unobservable in that image    same

The split is deliberate: disc-readable claims are asserted against the disc,
savestate-dependent ones live in plan/pcsx2-verification.md with their method.
What is not acceptable is a disc-readable claim living only in prose -- which is
how the tie i16[3] finding spent two commits before it had a test, and how several
older claims drifted before the roadmap reconciliation caught them.

docs/formats/core-data-regions.md

@@ -1804,3 +1804,34 @@ fixed at `i16[4]`/`i16[5]`, 73.6% of the time, unexplained". The field position
 was right; the 73.6% was a population average over three encodings, which is
 exactly the pooled-number problem rule 3a describes -- partitioning by the one
 variable that separates them turns a mystery into a lookup.
+
+### Which of these findings are asserted
+
+Not every claim here has a test behind it, and the recent ones are the ones most
+likely to be lost. Audit against `crates/gc-extract/tests/disc.rs`:
+
+    claim                                        asserted in
+    -------------------------------------------  -----------------------------------
+    tie vertex element is 16 bytes                tie_vertex_element_is_16_bytes_
+                                                  with_fixed_texcoords
+    layout selected by i16[3] HIGH byte          tie_vertex_layout_is_selected_by_
+                                                  i16_3_high_byte
+    blocks self-delimiting on 0xf6               tie_classes_resolve_through_both_
+                                                  indirections (per-block assert)
+    packets == 0 means no block at that LOD      same test
+    packets[0] == 256 on 1,864 of 1,864          same test
+    chunk record length uniform per chunk         tie-classes test + chunk_records_
+                                                  start_16_byte_aligned
+    moby class IDs in one body slot per type     moby_class_ids_sit_in_one_slot_
+                                                  per_chunk_type
+    collision payload verbatim in RAM            NOT assertable here -- needs a
+                                                  savestate, so it lives in
+                                                  plan/pcsx2-verification.md
+    tfrag patch bytes all rewritten by LOD       same -- savestate-dependent
+    morphing is unobservable in that image       same -- savestate-dependent
+
+The split is deliberate: anything readable from the disc is asserted against the
+disc, and anything that needs a running PCSX2 is documented in the plan file with
+its method. What is *not* acceptable is a disc-readable claim living only in
+prose, which is how the tie `i16[3]` finding spent two commits before it had a
+test.