Withdraw the tie "not a joint index" claim: the measurement never settled it

Revisited an older conclusion and found the numbers were fine but the inference
from them was not.

The claim was: i16[3] in a tie vertex is not a skin/joint index, because vertices
sharing a value are 0.95x FARTHER apart than vertices differing in it.

    mean pairwise distance, same slot-3 value        14,481
    mean pairwise distance, different slot-3 value  13,795
    ratio                                              0.95x
    control: same position-x bucket                   8,105

The measurements are correct, and the control shows the test works. What does not
follow is the conclusion. The premise was "vertices sharing a joint sit together",
and that is only true for a TIGHTLY LOCALISED joint. It is false in the cases that
are common:

  * a rigid tie object -- a leaf, a banner, a piece of foliage -- puts every vertex
    on joint 0, so "vertices sharing a joint" IS the whole mesh and the mean
    distance is the mesh's own diameter
  * a root or hip bone's influence region can span most of a mesh
  * bone weights fall off gradually, so membership is not a spatial partition

A 0.95x ratio is precisely what a rigid object bound to one joint PREDICTS.
Absence of clustering is fully consistent with the joint reading; the test never
had the power to separate them. A negative result I did not expect was reported
as a disproof.

This makes the hypothesis STRONGER, for an independent reason: MobyInstance carries
jointCnt at 0x57 and jointCache at 0x58, so this engine demonstrably has joints and
per-moby joint state. A per-vertex field in 0..=254 is exactly the shape of a
joint index.

What was always established still stands, and is all that was: slot 3 is per vertex
(50 distinct values per packet) and not shared across LODs (75.3% same-class
against a 78.7% control). The LOD result is the one thing arguing against a joint
index, though two LODs binding a rigid mesh identically would produce it without
being informative.

So: not understood, with the joint reading now the LEADING CANDIDATE rather than a
disproved one. Corrected in the format file and the roadmap, including the second
mention added two commits ago.

This is the sixth correction in this session to withdraw a conclusion rather than
sharpen one, and the first where the measurement was sound and only the reading
was wrong -- which is the hardest kind to catch, because the number looks right and
is quoted in the commit message as well as the doc.

docs/roadmap.md

@@ -353,10 +353,13 @@ Phase 1 hands over the extents; this phase works out what each one contains.
 - [~] The remaining tie vertex **fields are not named**, and two readings are now
       excluded. `i16[6]`/`i16[7]` are constant across a whole draw packet in
       43%/34% of records, so they are usually per-packet rather than per-vertex.
-      `i16[3]` is per-vertex (50 distinct values per packet) but **not a skin or
-      joint index**: vertices sharing it are 0.95x *farther* apart than vertices
-      differing in it, against a control that halves. It is also unshared across
-      LODs. Recorded as not understood rather than guessed.
+      `i16[3]` is per-vertex (50 distinct values per packet) and unshared across
+      LODs (75.3% against a 78.7% control). **An earlier note here called it "not
+      a joint index" on a 0.95x distance ratio; that was an over-read and is
+      withdrawn.** A rigid object bound to joint 0 makes "vertices sharing a
+      joint" the whole mesh, so absence of clustering is what a joint index
+      predicts. With `MobyInstance.jointCnt` now named, the joint reading is the
+      leading candidate, not a disproved one.
       `i16` range with 10,803-13,421 distinct values each. `i16[0..2]` are most
       likely position, but that is not established.
 - [~] `shrub` — class table done (48-byte entries, not 32; reading shrub at