Tie vertex regions are two encodings, not one; mark Phase 3's port done

Read up on the five commits that landed since f1f0b51. The headline is e5cd3df,
which retracts my tie vertex position claim: the stride is not 16. The LOD1/LOD2
sharing evidence survives, because it is stride-insensitive, but the element
layout and the 95,612 count do not. This commit works on what that retraction
opened rather than trying to rescue it.

The split 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
    (levels 0-5, every record with vert_size > 0)

So roughly half of all tie records address their vertex data as VIF packets and
half as a flat 16-byte array. Flat records repeat a 16-byte unit whose last word
is constant at 0x00001000 and whose third word walks down
f000, e000, d000, c000; VIF records start with e.g. 0xf5c1a3c5, cmd 0x75 num 193.

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 exactly the rule a decoder would reach for. The 10 that carry one kind are the
rarest sizes, not a band.

This also explains why the flat reading looked convincing rather than arbitrary.
In a flat record, i16[6] is 0x1000 and i16[7] is 0x0000 at the end of each unit --
the (-1, 0) / (1, 0) corner pair a texture coordinate makes in 12.4 fixed point.
That is where the earlier texcoord reading came from, and it holds cleanly on the
half of the records that are flat. It was never wrong about those; it was applied
to all of them.

It does not settle the stride. It says the region has to be dispatched on encoding
before anything inside it can be read, which is why no single flat stride fits
every record. Asserted in tie_vertex_regions_split_between_vif_and_flat.

ALSO: the roadmap still listed two Phase 3 items as open that a94704d has already
done -- "Port the masking and code-identity logic" and "Relocation::func and
Relocation::data". Both exist, are exported, and the masking is verified against
the disc: the masked form of a level-01 function (858 words at 0x2a3b88) is found
exactly once on each of the other 26 overlays. Both now marked done with the
evidence attached, rather than left stale.

I ran clippy --fix over overlay_reloc.rs, saw it rewrite 110 lines of the new
Phase 3 code, reverted it. The changes were cosmetic -- redundant `as u32` and
reflow -- but it is not my code and the remaining warnings are the author's to
address. Its 11 warnings are pre-existing and left alone.

258 tests.

docs/formats/core-data-regions.md

@@ -2763,3 +2763,40 @@ The general guard is now positive rather than a comment.
 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
+
+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
+    (levels 0-5, every record with vert_size > 0)
+
+The two kinds look like this:
+
+    flat, class 0 rec 0, 1024 bytes          VIF, class 1 rec 0
+      +0   0x27667942  0x0062fbf1              +0   0xf5c1a3c5  CODE cmd 0x75 num 193
+      +8   0x0000f000  0x00001000              +4   0x00aef9c2
+      +16  0x67264af1  0x005f0585              +8   0x10001000
+      +24  0x1000e000  0x00001000              +12  0x00001000
+      ...  16-byte units repeating, third word
+           walking down f000, e000, f000,
+           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.
+
+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
+reading fit some records well -- `i16[6]` being `0x1000` and `i16[7]` `0x0000` at
+the end of each 16-byte unit is the (-1, 0) / (1, 0) corner pair that a texture
+coordinate produces in 12.4 fixed point, which is where the earlier texcoord
+reading came from and why it looked convincing on the records that are flat.
+
+Asserted in `tie_vertex_regions_split_between_vif_and_flat`.