re: the capture logs are the sharing oracle -- engine reuses a buffer only 3.4% of the time

The raw Canary capture logs from the 2026-07 sessions are still on disc at
/sylph-home/re/shipcap/xenia_ship_capture_*.log, and their DRAW lines carry
vbase -- the GPU vertex base, i.e. ground truth for which buffer the engine draws
a part from. That is precisely the oracle the shared-decode question needs, and
it needs no new capture run.

Restricted to the ship-geometry stride 24, across the three logs: 6093 draws from
2291 distinct vbases, and only 77 vbases (3.4%) drawn more than once. So one
buffer serving several parts is the exception in the engine, while our decoder
has 19% of resources sharing geometry.

The measures differ (draws-per-buffer vs resources-per-geometry) so this is
evidence not proof, but it points the same way as e106_bdy_02 == e106_bdy_03_m:
much of that 19% is anchoring error rather than asset reuse.

Per-part use is already available: correlate_capture matches a draw to a resource
by vcount plus decoded positions, and the same match yields each part's vbase --
so two resources our decoder gives identical geometry can be checked directly,
different vbase meaning our shared decode is wrong.

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

docs/re/structures/xbg7-mesh.md

@@ -552,3 +552,34 @@ legitimate (a mirrored twin pair genuinely shares one geometry), and some is
 certainly not** — and cross-container consistency cannot tell them apart. A test
 that can: compare a shared pair against a runtime capture, which is ground truth
 for what the engine actually draws.
+
+### The capture answers it at population level — and the logs are still on disc
+
+`/sylph-home/re/shipcap/xenia_ship_capture_*.log` (kept from the 2026-07 capture
+sessions) carry the raw per-draw lines the baked table was distilled from:
+
+```
+DRAW vbase=0x150CCAC0 stride=28 vcount=1 indices=1 prim=1 vs=0x…
+DRAW vbase=0x150CCAC0 stride=24 vcount=10891 indices=18 prim=4 vs=0x…
+```
+
+`vbase` is the GPU vertex base — **ground truth for which buffer the engine draws
+a part from**, which is exactly the oracle the sharing question needs. Over the
+three logs, restricted to the ship-geometry stride 24:
+
+- **6 093 draws from 2 291 distinct vbases**
+- **only 77 vbases (3.4 %) are drawn more than once**
+
+So in the engine, one buffer serving several parts is the **exception**. Our
+decoder currently has **19 %** of resources sharing geometry with another. The
+two figures are not the same measure — draws-per-buffer versus
+resources-per-geometry — so this is evidence rather than proof, but it points the
+same way as the `bdy_02` ≡ `bdy_03_m` case: **much of that 19 % is anchoring
+error, not asset reuse.**
+
+**How to use it per-part:** `correlate_capture` already matches a draw to a
+resource by `vcount` plus decoded positions. The same match yields, for each
+part, the `vbase` the engine used — so two resources that our decoder gives the
+same geometry can be checked directly: different `vbase` in the capture ⇒ our
+shared decode is wrong. That is the per-part oracle any future anchor work should
+be validated against, and it needs no new capture run.