phase11: cookbook 105-106 — re-read granularity as a tunable; filter determines failure class

105: the pointer re-read granularity is a DIAL, measured in both directions by worker D --
re-read per store (700 B row, 46 times, matched), once per block (276 B row, matched),
per statement (80 bytes too long), and never (does not match). Cause is aliasing. It is the
same property as finding 45's named-locals family but as a COUNT rather than a yes/no.
Plus: a genuinely uninitialised read in the original must be preserved, not corrected.

106: which failure class a row lands in depends on the FILTER, not the band. Worker D's
cheap rows fail on frame/combiner/allocation/batch-shape and never on the branch
diagnostics, so those belong on tie-break-dense rows. Route a diagnostic to the row shape
it matches rather than broadcasting it.

docs/MATCHING_COOKBOOK.md

@@ -1621,3 +1621,37 @@ log.
 **Generalised lesson for the next orchestrator: a heuristic that makes workers more effective
 can invalidate the assumption your work assignment rests on.** Adjacency optimised *which* row
 to take without anyone revisiting *who owns it*.
+
+### 105. The pointer re-read granularity is a TUNABLE, measured in BOTH directions (worker D)
+
+How often the source re-reads a sub-object pointer is a **per-site source choice** and it is
+decisive in both directions. Worker D has now measured both ends of the range:
+
+| row | granularity | result |
+|---|---|---|
+| `0x8006BC74` (700 B) | re-read **before every store** — 46 times | matched |
+| `0x800320D8` (276 B) | re-read **once per block** — one assignment per block | matched |
+| same row, macro-style | re-read **per statement** | **356 vs 276 — 80 bytes too long** |
+| same row, one read for the whole function | never re-reads | does not match |
+
+The cause is aliasing: each store through the pointer could write the pointer's own slot, so a
+source that re-dereferences at every statement forces a fresh load. **This is the same property
+as finding 45's named-locals family, but as a *count* rather than a yes/no** — so it is a dial
+you can turn, not a rule to apply.
+
+**And a companion property worth preserving rather than "fixing":** `0x800320D8` leaves `v.b`/`v.c`
+**uninitialised** on the single-word path and then subtracts them. **That uninitialised read is a
+real property of the original, not a reconstruction error** — worker D recorded it in the file
+header so nobody corrects it. `0x80079B34` reads `x[3]`/`y[3]` the same way. A worker who
+"fixes" such a read loses the match.
+
+### 106. Which failure class a row lands in depends on the FILTER, not the band (worker D)
+
+Worker D's calibration: with the redundancy filter, its cheap rows fail on **frame/displacement
+(59), combiner fold (63), allocation (45/82), and batch shape** — and **not once** on the four
+branch/order diagnostics (100).
+
+So the branch diagnostics are the right tool for **tie-break-dense** rows (worker C's), and the
+wrong tool for **repetitive** rows. **Route a diagnostic to the rows whose shape it matches,
+rather than broadcasting it to everyone** — a correct lever applied to the wrong row class just
+consumes attempts.