re: the correct anchor is already a candidate -- locality selects it, monotonicity does not

Enumerating every validating candidate for e303_wep_01 in Stage_S02 gives exactly
two:

  vb = 18403456   span 1600 x 2100 x 4800   <- taken, only because it is first
  vb = 52257440   span   49 x   23 x   42   <- correct, the size all 11 good
                                               containers give

So the scan is not missing anything; the wrong block merely appears earlier in
file order.

Monotonic anchoring is REFUTED as the constraint: recording each resource's
accepted anchor in descriptor order gives 25/47 increasing steps in Stage_S01 and
130/248 in Stage_S02, no better than chance. Locality holds instead -- in
Stage_S02 the descriptor neighbours anchor at 51974668 and 52218424, the correct
candidate is 52257440, and the wrongly-taken block sits at 18403456, two thirds
of the file from its own family.

Proposed rule, needing no new format knowledge: among validating candidates
prefer the one nearest the neighbouring resources' anchors, falling back to
first-match when there is no neighbour yet. It selects 52257440 here.

Not implemented: it moves the anchor for all 6294 resources, so it needs the
before/after measurement (decoded must not fall from 5480, inconsistent should
fall from 125) and then un-ignoring mesh_consistency_disc.

Instrumentation reverted; only docs land here.

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

docs/re/structures/xbg7-mesh.md

@@ -365,16 +365,39 @@ family of fixes: no threshold, no scoring, no "pick the best candidate" changes
 this, and the earlier attempt to add best-of-N selection in the grouped-pool
 anchor duly changed nothing.
 
-**The search space has to be constrained instead.** Two candidates, in order of
-how much new format knowledge they need:
+**The search space has to be constrained instead — and the fix is now pinned
+down.**
 
-1. **Per-resource data extents.** The XPR2 resource table gives each resource a
-   descriptor; if the geometry extent can be derived from it, restrict `starts`
-   to that range and the theft becomes impossible.
-2. **Monotonic anchoring.** If resources' data blocks follow descriptor order,
-   then resource *k*'s `vb` must lie after resource *k−1*'s — a cheap constraint
-   needing no new format knowledge. Testable against the 556 resources that
-   already decode consistently across containers.
+**The correct block is already in the candidate list.** Enumerating *every*
+validating candidate for `e303_wep_01` in `Stage_S02` gives exactly two:
+
+```
+vb = 18 403 456   span 1600 × 2100 × 4800   ← what the decoder takes, only because it is first
+vb = 52 257 440   span   49 ×   23 ×   42   ← correct: the same size all 11 good containers give
+```
+
+So nothing needs to be found that the scan is missing; the wrong one merely
+appears earlier in file order.
+
+**Locality picks the right one.** Recording each resource's accepted anchor in
+descriptor order shows that global **monotonicity is refuted** — only 25 of 47
+steps increase in `Stage_S01` and 130 of 248 in `Stage_S02`, i.e. no better than
+chance. But *neighbourhood* holds strongly: in `Stage_S02` this resource's
+descriptor neighbours anchor at **51 974 668** and **52 218 424**, its correct
+candidate is **52 257 440**, and the block it wrongly takes is at **18 403 456** —
+two thirds of the file away from its own family.
+
+**Proposed rule:** among candidates that validate, prefer the one **nearest the
+anchors of the neighbouring resources** (equivalently: decode in descriptor order
+and prefer candidates close to the previous resource's anchor), falling back to
+first-match when there is no neighbour yet. That needs no new format knowledge,
+and it selects `52 257 440` here.
+
+**Not implemented.** It changes the anchor for every one of the 6 294 resources,
+so it needs the before/after measurement — decoded count must not fall from
+5 480, and the inconsistency count should fall from 125 — plus the ignored test
+[`mesh_consistency_disc.rs`](../../crates/sylpheed-formats/tests/mesh_consistency_disc.rs)
+un-ignored once it passes.
 
 ### Where the mis-decode is *not*: the grouped-pool anchor