re: correct the 3.4% reuse figure -- the capture dedups by (vbase, transform)

Read off the emulator patch rather than inferred: CaptureShipDrawForRE dedups by
(vbase, WVP hash), so a buffer drawn repeatedly at one transform appears once.
The 3.4% counts multi-instance placement, not buffers serving several parts, and
is not the population evidence about sharing it was written up as. Also pins
vcount = buffer capacity and indices = that draw's num_indices.

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

docs/re/structures/xbg7-mesh.md

@@ -570,12 +570,22 @@ 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
+⚠️ **That 3.4 % measures less than it first appears — corrected 2026-08-12.**
-decoder currently has **19 %** of resources sharing geometry with another. The
+The capture code (`command_processor.cc`, `CaptureShipDrawForRE`) de-duplicates
-two figures are not the same measure — draws-per-buffer versus
+by **(vbase, WVP-transform hash)**, so a buffer drawn many times *at one
-resources-per-geometry — so this is evidence rather than proof, but it points the
+transform* — which is what a mesh split into per-material sub-draws looks like —
-same way as the `bdy_02` ≡ `bdy_03_m` case: **much of that 19 % is anchoring
+appears **once**. The figure therefore counts buffers drawn at *several
-error, not asset reuse.**
+placements* (multi-instance parts), not buffers serving several parts. It is not
+the population-level evidence about sharing it was first written up as; the
+`bdy_01_l`/`bdy_02_l` result below is direct evidence and stands on its own.
+
+Two more field semantics, read off the same patch rather than guessed:
+`vcount = fetch.size × 4 / stride` is the **buffer's capacity**, not the draw's
+vertex usage (which is why it matches a decoded resource's vertex count so
+exactly), and `indices` is `VGT_DRAW_INITIATOR.num_indices`, **that draw's**
+index count. So the 119-vertex twin logging `indices=21` against our 246-index
+marker most likely means the engine issues the mesh as several sub-range draws
+and the log keeps the first — likely, not proven.
 
 **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