re: the twins' correct block validates -- distinctness is a real fix; eng_02_l is not

debug_try_anchor asks validate_block directly at the capture-proven offsets. Both
119-vert twin buffers are accepted by both twins (so the correct block lost the
first-match race, and a distinct assignment fixes it); the drawn 51-vert bridge
buffer is accepted by both bridge resources; eng_02_l's proven offset is rejected
outright, even with the pad widened to 64 -- a validator gap, not a selection one.

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

crates/sylpheed-formats/examples/try_anchor.rs

@@ -0,0 +1,17 @@
+//! Does the capture-proven offset validate for the resource that should own it?
+use sylpheed_formats::mesh::debug_try_anchor;
+fn main() {
+    let a: Vec<String> = std::env::args().collect();
+    let bytes = std::fs::read(&a[1]).unwrap();
+    // The production scan tries pads 0..=3; pass a bigger one to ask whether the
+    // block would validate at all with a wider index/vertex gap.
+    let max_pad: usize = std::env::var("MAX_PAD").ok().and_then(|v| v.parse().ok()).unwrap_or(3);
+    for pair in a[2..].iter() {
+        let (name, off) = pair.split_once('@').unwrap();
+        let off = usize::from_str_radix(off.trim_start_matches("0x"), 16).unwrap();
+        match debug_try_anchor(&bytes, name, off, max_pad) {
+            Some((v, i, pad)) => println!("{name:22} @ 0x{off:x}  ACCEPTED  v={v} idx={i} pad={pad}"),
+            None => println!("{name:22} @ 0x{off:x}  rejected"),
+        }
+    }
+}