fix(mesh): anchor XBG7 resources by neighbourhood -- inconsistency 125 -> 63, ships render right

anchor_pool_mesh took the FIRST candidate in file order from a container-global
vertex-run scan, so a resource could be handed another resource's block whenever
both shared (stride, vertex count, index count). Both blocks are real geometry and
both pass every quality gate, so only position separates them.

anchor_pool_mesh_near now tries candidates in order of distance from a reference,
and anchor_models_filtered runs two passes: pass 1 anchors first-match to learn
where resources land, pass 2 re-anchors each resource preferring the median anchor
of its +/-2 descriptor neighbours. Too few anchored neighbours -> keep pass 1, so
nothing regresses to guesswork.

  before  decoded 5480/6294  shared 681  inconsistent 125
  after   decoded 5480/6294  shared 681  inconsistent  63

Coverage unchanged, inconsistency halved. e303_wep_01 decodes to 49x23x42 in ALL
containers now, and e106 renders as a destroyer instead of a slab -- its two
shared turrets symmetric at X[-203,-154] and X[154,203]. That resolves the
user-reported "capital ships assemble wrong" for this cause.

The filtered path needed care: models_named (what the viewer uses) dropped
non-wanted resources, which would have left filtered decodes with no
neighbourhood and silently kept the old behaviour. Resources are now collected
regardless of the filter, but only the asked-for ones and their +/-2 neighbours
are decoded in pass 1, so a filtered decode stays proportional to what was asked.

63 cases remain; mesh_consistency_disc stays ignored and now records 63, not 125.

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

docs/re/BACKLOG.md

@@ -153,6 +153,11 @@ report needs re-grounding against a specific ship and a specific expectation.
 
 ---
 
+## ✅ FIXED 2026-08-12 — it was a mis-decode, and the anchor now uses locality
+
+> Resolution at the end of this entry. Kept in full because the two wrong turns
+> along the way (a "stray volume", then "monotonic anchoring") are the useful part.
+
 ## ⚠️ The format layer is NOT exonerated — but the cause is a MIS-DECODE, not a stray volume
 
 **Found 2026-08-11 by finally doing the visual**, which the notes above kept
@@ -255,3 +260,19 @@ worth fixing regardless — it is the same one-way-test shape as the earlier
 Also unchanged: only **two** cross-id placements exist fleet-wide (`e303_wep_01`
 on `e101` ×24 and `e106` ×36, across 335 assembled ships), so cross-id mounting is
 a narrow, real feature rather than a systemic guess.
+
+---
+
+## Resolution (2026-08-12)
+
+`anchor_pool_mesh` took the **first** candidate in file order from a
+container-global scan, so a resource could be handed another resource's block
+whenever both shared `(stride, vertex count, index count)`. Fixed by anchoring
+each resource near its **descriptor neighbours** (two-pass: learn, then re-anchor).
+
+- decoded **5 480 / 6 294 unchanged**, inconsistent **125 → 63**
+- `e106` renders correctly ([after](captures/e106-static-assembly-fixed.png))
+- the user-reported "capital ships assemble wrong" is **resolved** for this cause
+
+Still open from this entry: `static_assembly_matches_runtime_capture` walks only
+the capture's parts, so **extra** static placements still cannot fail it.