Ground first infrastructure record prelude

docs/control-loop-atlas/runtime-roots-camera-and-support-families.md

@@ -2966,6 +2966,15 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   infrastructure question is no longer whether the fixed `0x55f2` row hides the child count or
   saved primary-child ordinal at all. Those values now have to live outside the fixed row, most
   likely in the surrounding payload-stream header or compact-prefix regime above `0x0048dcf0`.
+  The outer prelude is explicit now too: direct disassembly of `0x0048dcf0` shows it reading one
+  `u16` child count through `0x00531150`, zeroing `[this+0x08]`, and conditionally reading one
+  saved primary-child byte before the per-child callback loop begins. Grounded `q.gms` bytes now
+  also show the first `0x38a6` record starting immediately after the shared owner-local dword with
+  `child_count = 1`, `saved_primary_child_byte = 0xff`, and the first child `0x55f1` opening at
+  offset `+0x3`. So the remaining infrastructure question is no longer “what kind of value should
+  the save-side probe be looking for above the fixed rows?”; it is the narrower partitioning
+  problem of how the observed `0x55f3`-to-next-`0x55f1` gaps divide between the two `0x52ebd0`
+  flag bytes and the next record’s `u16 + byte` prelude.
   The child loader family is explicit now too: local `.rdata` at `0x005cfd00` proves the
   `Infrastructure` child vtable uses the shared tagged callback strip directly, with
   `+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining

docs/rehost-queue.md

@@ -116,6 +116,15 @@ Working rule:
   primary-child ordinal at all; those outer-header values now have to live outside the fixed row,
   most likely in the surrounding payload-stream header or compact-prefix regime above
   `0x0048dcf0`.
+- The outer prelude itself is tighter now too: direct disassembly of `0x0048dcf0` shows it reading
+  one `u16` child count through `0x00531150`, zeroing `[this+0x08]`, and conditionally reading one
+  saved primary-child byte before the per-child callback loop runs. Grounded `q.gms` bytes now also
+  show the first `0x38a6` record starting immediately after the shared owner-local dword with
+  `child_count = 1`, `saved_primary_child_byte = 0xff`, and the first child `0x55f1` opening at
+  offset `+0x3`. So the next infrastructure question is no longer “what kind of values are we
+  looking for above the fixed rows?”; it is the narrower partitioning problem of how the observed
+  `0x55f3`-to-next-`0x55f1` gaps divide between the two `0x52ebd0` flag bytes and the next
+  record’s `u16 + byte` prelude.
 - Reconstruct the save-side region record body on top of the newly corrected non-direct tagged
   region seam (`0x5209/0x520a/0x520b`, stride hint `0x06`, `Marker09` record stems) now that the
   `0x55f3` payload is known to be fully consumed by the embedded profile collection on grounded