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/roadmap.md

@@ -556,8 +556,12 @@ linked at different addresses. ReRAC solves this by masking relocations — `j`/
 them, and `$gp`-relative operands — then matching the masked words to find a
 reference function's copy on another overlay.
 
-- [ ] Port the masking and code-identity logic
-- [ ] `Relocation::func` and `Relocation::data`
+- [x] Port the masking and code-identity logic (`gc_formats::overlay_reloc`,
+      `mask` / `address_refs` / `key`). **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, and 0 times on its own level.
+- [x] `Relocation::func` and `Relocation::data`, plus `is_identity`, `same_code`
+      and `copies`
 - [x] `$gp` for this game (`0x001AEFF0`, against R&C1's `0x166c00`) -- confirmed
       by `OpenRAC/rac2-gc-decomp` `docs/LEVELS.md` for all 27 levels
 - [ ] Extend the level table from 19 to 27