ship_capture: bake e106 COMPLETE from the 2026-07-26 F10 capture — all 8 parts

The second F10 capture (ship at _m LOD distance) closes e106 entirely: all 8
parts placed including the bridge both earlier captures missed, cross-validating
the doc's 7 known translations to 0.1 units and adding brg_01 at the exact
centreline (0, 153.3, -164.0).

Matching hardened by what the real capture taught us:
- LOD-aware: each part tries every variant vcount (base/_m/_l/_d) — a distant
  ship draws its LOD copies, same local frame.
- Position-validated, SET-based, against the UNION of a part's variants: buffer
  order != decode order, and one draw's vcount equalled the _m count while its
  buffer held the FULL 1633-vert geometry. A coincidental vcount (foreign
  51-vert mesh vs the bridge) is rejected by geometry.
- Runtime mirror handled: twins share one file geometry; the engine uploads the
  starboard copy X-reflected. Mirror-validated draws bake diag(-1,1,1) and the
  viewer reverses triangle winding for det<0 so front faces stay outward.
- Near-axis rotation entries snapped to exact 0/+-1 for a clean table; eng_01
  keeps its genuine 30-degree nacelle rotation.

data/ship_placements.txt now ships e106 (viewer renders via the captured table);
embedded_e106_is_complete locks the baked data. part_pos + capture_match helper
examples added. 10 ship_capture tests; 80 formats-lib tests green; viewer builds.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/re/ship-placement-runtime-capture.md

@@ -1,9 +1,10 @@
 # Capital-ship part placement — runtime capture (ground truth)
 
-**Status:** pipeline working end-to-end for one ship (`e106` ADAN Destroyer);
-correlator recovers exact ship-relative transforms. **Bake plumbing landed** — the
-correlator is now a tested library module and the viewer prefers a captured table;
-only real capture data still needs baking in (needs the emulator + F10).
+**Status:** ✅ **`e106` ADAN Destroyer FULLY BAKED (2026-07-26)** — all 8 parts
+(incl. the bridge both earlier captures missed, and the runtime-mirrored
+starboard hull) recovered from a second F10 capture and checked in to
+`data/ship_placements.txt`; the viewer renders it via the captured table.
+Remaining ships (e105, f101, f105/f106, turrets) need one capture each.
 
 ## Problem
 
@@ -71,6 +72,24 @@ Two capture formats are accepted (auto-detected): the F10 ship-capture snapshot
 draws by vertex-buffer `base`, `vcount = size_words/stride_words`). So a capital
 ship seen in a normal instrumented run can be baked without a dedicated F10 pass.
 
+### Matching rules (learned from the real 2026-07-26 capture)
+
+- **LOD-aware**: a distant ship draws its `_m`/`_l` copies — same part, same
+  local frame, different vcount. Each part tries every variant vcount.
+- **Position-validated**: a vcount hit alone can be a coincidence (a foreign
+  51-vert mesh nearly hijacked the bridge slot). Every candidate draw's dumped
+  positions must be found in the part's decoded position set or it is rejected.
+  Validation is **set-based** (buffer order ≠ decode order) against the **union**
+  of the part's variants — the real capture had a draw whose `vcount` equalled
+  the `_m` count while its buffer held the FULL-detail geometry.
+- **Runtime mirror**: a port/starboard pair shares one file geometry; the engine
+  uploads the second instance **X-reflected**. A draw that validates only under
+  X-negation is accepted as the mirror, and the placement bakes `diag(−1,1,1)`
+  (the viewer reverses triangle winding for det < 0).
+- The mission ship shader can be a different hash per lighting variant
+  (`0x3A0829CC71516789` in this capture) — the F10 path doesn't filter by hash,
+  it validates by geometry instead.
+
 `examples/correlate_capture.rs` is the CLI wrapper:
 ```
 SYLPHEED_ISO=… cargo run --release --example correlate_capture -- \