Record save-invariant peer-site payload stride

docs/rehost-queue.md

@@ -91,7 +91,8 @@ Working rule:
   - the periodic-company trace now also surfaces the save-side `0x5dc1` payload/status summaries
     already parsed from the `0x36b1` triplet seam; on grounded `p.gms` the payload dword lane is
     almost entirely unique while the status kind stays `unset`, and the dominant adjacent payload
-    delta is `0x00000780` across `1908` steps
+    delta is `0x00000780` across `1908` steps; grounded `q.gms` shows the same dominant adjacent
+    delta `0x00000780` across `1868` steps
   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
@@ -118,10 +119,10 @@ Working rule:
     `0x0040ceab -> 0x0045c150` / `0x0040d1a1 -> 0x0045c310` /
     `0x0040cd70 seeds [site+0x3cc/+0x3d0] from 0x62b2fc / 0x62b268`
   - use the new `0x5dc1` payload/status summary in the same trace as negative evidence too:
-    the current `profile_payload_dword` lane behaves like a monotone ladder (`dominant adjacent
-    delta 0x780`) 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
+    the current `profile_payload_dword` lane behaves like a save-invariant monotone ladder
+    (`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
   - 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