Compare region fixed-row candidate families

docs/rehost-queue.md

@@ -557,6 +557,20 @@ Working rule:
   appear to live in either the pre-`0x55f1` prefix band or the fixed `0x55f2` reserved dword band
   on grounded ordinary saves. That shifts the next region payload-comparison pass onto later body
   seams, not back onto the prefix or fixed-policy chunk.
+- The new fixed-row run candidate probe pushes that same payload search one seam later, but it is
+  not grounded yet: on both `p.gms` and `q.gms` it finds high-signal counted runs keyed to the
+  live region count `145` with fixed row stride `0x29` before the tagged `0x5209/0x520a/0x520b`
+  region collection, yet the top candidate offset is not stable (`p.gms = 0xd13239`,
+  `q.gms = 0xd2d7d7`). So the next region payload pass should compare candidate lane-shape
+  fingerprints across saves rather than promoting any one absolute pre-header offset as the fixed
+  restore seam.
+- The new two-save `runtime compare-region-fixed-row-runs <left.gms> <right.gms>` report now does
+  that comparison directly. Current result: `p.gms` vs `q.gms` has `0` exact shape overlaps, and
+  the only coarse family overlaps are lower-ranked fully mixed candidates where every dword lane is
+  still simultaneously small-nonzero and partially-zero. That means the fixed-row scan remains
+  useful negative evidence, but it is still not honest to promote as the missing region restore
+  seam; the next region pass should stay focused on later restore owners or a more selective row
+  family discriminator above this mixed pre-header corpus.
 - The rest of `0x00455fc0` is ruled down further now too: after the `+0x48` callback it only runs
   `0x0052ebd0`, which reads two one-byte generic flags through `0x531150` into base object bytes
   `[this+0x20]`, `[this+0x8d]`, `[this+0x5c..+0x61]`, `[this+0x1ee]`, `[this+0x1fa]`, and