re: exact anchor offsets (GameMesh.vbuf_offset) -- correcting yesterday's defect table

The first read of the capture-truth table located our resources by searching the
container for their leading vertices, which reads much worse than reality: the
same leading run occurs at several offsets in one container. GameMesh now carries
the offset the anchor scan actually chose, so the comparison is exact -- 4 of the
ship's drawn buffers are anchored correctly, 2 are the twin collapse, and 2 are
real mis-anchors of a size we do decode (brg 51 verts, eng_02_l 44).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

crates/sylpheed-formats/src/mesh.rs

@@ -115,6 +115,12 @@ pub struct GameMesh {
     pub indices: Vec<u32>,
     /// Sub-mesh / node name from the descriptor, when available.
     pub name: Option<String>,
+    /// Byte offset of this sub-mesh's vertex buffer inside the container, when
+    /// the decode path knows it. The content-anchored stage path does — and a
+    /// runtime capture names the same offset (a draw's `vbase` is this plus the
+    /// container's load address), so this is what makes an anchor checkable
+    /// against ground truth. See `examples/shared_vbase_check.rs`.
+    pub vbuf_offset: Option<usize>,
 }
 
 /// A model = the set of sub-meshes recovered from one XPR2 container's first
@@ -376,6 +382,7 @@ impl Xbg7Model {
                 uvs,
                 indices,
                 name: None,
+                vbuf_offset: Some(vb),
             });
             off = align16(ve) - base;
         }
@@ -976,6 +983,7 @@ fn read_pool_mesh(
         uvs,
         indices,
         name: None,
+        vbuf_offset: Some(vb),
     }
 }