Correct my own "VIF packets" reading: the split is real, the identification is not

Last commit read bit 31 of a tie vertex region's first word as "VIF code word"
and told a two-encoding story on it. The split is real; the identification is
wrong, and I checked it before building anything on top.

Walking those regions as VIF packets, levels 0-2, 914 records:

    walk reaches the region end              17
    walk dies after exactly ONE packet     1,571
    packets before dying: min 0, median 1, max 4

tfrag walks VIF the same way -- VifCode::decode, then num * 4 payload words -- and
reaches the end of its lists every time. So the walk is not the problem; these
regions are not VIF packet streams. Bit 31 is set on whatever this word actually
is, and that is still unknown.

The specific thing that made me overreach: I quoted 0xf5c1a3c5 as "a VIF code
word, cmd 0x75 num 193" and treated that as establishing the format. Decoding one
word as a packet header says nothing about whether the next 193 words are its
payload. Here they are not -- the walk dies immediately after.

This is the third time in this area that one plausible word produced a confident
story: the 305x class-ID slot, the UV-corner texcoords, and now this. All three
shared a shape -- a single readable item at the head of a population, treated as
evidence about the whole. The bit is the only thing the two kinds reliably
differ on, so it stays; the name goes.

The test now asserts BOTH the split and the walk failure, which is the part worth
keeping. If these ever do turn out to be VIF, the test fails and says so, rather
than two findings drifting apart silently -- which is how "half VIF, half flat"
would have sat in the docs indefinitely.

Docs corrected in both roadmap and format file, including the quoted example.

258 tests.

docs/formats/core-data-regions.md

@@ -2764,14 +2764,18 @@ that every record except the last is exactly its own offset delta long, and that
 1,509 chunks contain 1,252 with ragged deltas. A regression to a single sampled
 stride fails immediately and says which chunk and which record.
 
-## The tie vertex region has two encodings, not one
+## CORRECTED: the tie vertex region splits in two, but not into "VIF and flat"
+
+This section previously read bit 31 of the region's first word as "this is a VIF
+code word", and told a two-encoding story on it -- half VIF packets, half flat.
+The split is real. **The identification is not.**
 
 The stride retraction found the vertex region is not a uniform array -- some runs
 4 bytes, some 16, run length varying. The split that accounts for it is visible
 in the region's first word: a VIF code word has bit 31 set.
 
-    first word is a VIF code word   2,007
-    first word is not               2,102
+    first word has bit 31 set      2,007
+    first word has bit 31 clear    2,102
     (levels 0-5, every record with vert_size > 0)
 
 The two kinds look like this:
@@ -2786,11 +2790,33 @@ The two kinds look like this:
            d000, d000, c000, c000; last
            word constant at 0x00001000
 
-So roughly half of all tie records address their vertex data as **VIF packets**
-and half as a **flat 16-byte array**. The split is overwhelmingly *not* a
-function of `vert_size` -- 62 of the 72 values carry both kinds -- so "short
-objects are VIF, long ones are flat" is false, which is the rule a decoder would
-otherwise reach for. The 10 that carry one kind are the rarest sizes, not a band.
+So roughly half of all tie records begin with a word that has bit 31 set and
+half do not. The split is overwhelmingly *not* a function of `vert_size` -- 62 of
+the 72 values carry both kinds -- so "short objects are one thing, long ones
+another" is false, which is the rule a decoder would otherwise reach for.
+
+### They are not VIF streams
+
+Bit 31 set is exactly what a VIF code word has, and that was the whole basis for
+calling them VIF. Walking them as VIF packets says otherwise. Levels 0-2, 914
+records:
+
+    walk reaches the region end              17
+    walk dies after exactly ONE packet     1,571
+    packets before dying: min 0, median 1, max 4
+
+`tfrag` walks VIF the same way -- `VifCode::decode`, then `num * 4` payload words
+-- and reaches the end of its lists every time. The walk is not the problem.
+These regions are not VIF packet streams, so bit 31 is set on whatever this word
+actually is, which remains unknown.
+
+The original example quoted `0xf5c1a3c5` as a code word with cmd `0x75` num 193.
+Decoding one word as a packet header says nothing about whether the next 193
+words are its payload, and here they are not.
+
+Both findings are now asserted in the same test, the split and the walk failure,
+so that if these ever do turn out to be VIF the test fails and says so rather
+than the two quietly drifting apart.
 
 This does not settle the stride. It says the region needs to be dispatched on the
 encoding before anything inside it can be read, and it explains why the flat