Promote peer-site 0x5dc1 companion lane

docs/rehost-queue.md

@@ -93,6 +93,11 @@ Working rule:
     almost entirely unique while the status kind stays `unset`, and the dominant adjacent payload
     delta is `0x00000780` across `1908` steps; grounded `q.gms` shows the same dominant adjacent
     delta `0x00000780` across `1868` steps
+  - the same trace now also promotes the one-byte `0x5dc1` companion lane explicitly: grounded
+    `p.gms` shows dominant companion byte `0x00` on `2023` rows with only `3` `0x01` rows, and
+    grounded `q.gms` shows dominant companion byte `0x00` on `2043` rows with only `14` `0x01`
+    rows; the old “pre-footer padding” hypothesis is now better understood as the probable
+    `[owner+0x242]` companion lane rather than anonymous slack bytes
   So the next owner question is no longer “what does the acquisition branch do?” or “which post-
   load owner replays linked-site refresh?” but “which concrete `0x00455b70` caller family applies
   to the live site rows, and which persisted lane becomes the selector bundle that ultimately
@@ -123,6 +128,10 @@ Working rule:
     (`dominant adjacent delta 0x780` on both `p.gms` and `q.gms`) rather than a compact selector
     family, so the next peer-site slice should treat that raw dword as a likely allocator/offset
     lane until a stronger selector interpretation appears
+  - use the new `0x5dc1` companion-byte summary in the same trace as positive evidence:
+    the probable `[owner+0x242]` lane is overwhelmingly `0x00` with a tiny `0x01` residue on both
+    grounded saves, so the next peer-site slice should treat that byte as a real typed companion
+    discriminator and ask which later `0x004014b0` / `0x00406050` predicates actually consume it
   - treat the peer-site selector seam itself as grounded enough for planning purposes
   - use the new structured restore/runtime field split in the same trace:
     restore subset