Summarize peer-site payload ladders

docs/rehost-queue.md

@@ -88,6 +88,10 @@ Working rule:
     three-arg wrapper `0x00530640`
   - `0x00490a79` is one chooser-side caller of `0x00455b70`, feeding literal selector
     `0x005cfd74` with fallback seed `0x005c87a8`
+  - 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
   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
@@ -113,6 +117,11 @@ Working rule:
     `grounded_direct_local_helper_strip`, and helper linkage
     `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
   - 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