re: the proven offsets ARE candidates -- these mis-anchors are selection failures

debug_vertex_run_starts exposes the anchor scan's candidate list: Stage_S01 has
15710 stride-24 starts and all three capture-proven offsets (0x3c55d8 twin,
0x40e418 bridge, 0x44a32c eng_02_l) are among them. anchor_pool_mesh takes the
first that validates, so an earlier lookalike wins. Scoped to the current
decoder's e106 cases; does not overturn the residual-51 finding.

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

crates/sylpheed-formats/src/mesh.rs

@@ -613,6 +613,27 @@ impl Xbg7Model {
     }
 }
 
+/// Diagnostic: the candidate vertex-buffer starts the stage anchor scan will
+/// consider for a given `stride`, for one container. A runtime capture names the
+/// offsets the engine really drew from (see `examples/shared_vbase_check.rs`), so
+/// asking whether a proven offset is in this list separates the two possible
+/// root causes of a mis-anchor: **absent** ⇒ the run scan misses it, **present**
+/// ⇒ the scan sees it and the selection picks another.
+pub fn debug_vertex_run_starts(bytes: &[u8], stride: usize) -> Vec<usize> {
+    if bytes.len() < 16 || &bytes[..4] != b"XPR2" {
+        return Vec::new();
+    }
+    let mut cur = Cursor::new(bytes);
+    let Ok(header) = Xpr2Header::read(&mut cur) else {
+        return Vec::new();
+    };
+    let data_base = header.header_size as usize;
+    if data_base >= bytes.len() {
+        return Vec::new();
+    }
+    vertex_run_starts(bytes, data_base, stride)
+}
+
 /// Scan the data section for offsets that begin a `stride`-sized unit-normal
 /// vertex run (NORMAL is `f16×4` at vertex offset +12). A run *start* is an
 /// offset whose normal is unit while the preceding stride slot's is not — i.e.