Decode infrastructure short trailing flag lane

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

@@ -2943,6 +2943,15 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   to the first string when absent. So the remaining payload question is no longer “where is the
   third string hiding?”; it is how the current dual-name save-side rows align with the full
   payload-stream grouping and the later tagged value roles.
+  That trailing-value strip is tighter now too: direct disassembly of the post-`+0x48` helper pair
+  `0x0052ebd0/0x0052ec50` shows two serialized single-byte lanes folded into bits `0x20` and
+  `0x40` of `[this+0x20]`. Grounded `q.gms` side-buffer probes now show that all embedded rows sit
+  inside complete `0x55f1 -> 0x55f2 -> 0x55f3` envelopes, every embedded `0x55f2` chunk is the
+  fixed `0x1a` bytes that `0x00455870` expects, and the dominant short trailing `0x55f3` span is
+  the `0x06`-byte form with flag pair `0x00/0x00` across `72` rows. So the next remaining
+  infrastructure question is no longer whether a short trailing lane exists; it is how those
+  compact-prefix regimes and short flag-byte pairs feed the child-count / primary-child restore
+  state above `0x0048dcf0`.
   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

@@ -95,6 +95,13 @@ Working rule:
   infrastructure pass should stop asking whether the shared tagged callback sequence is present at
   all and instead decode the short `0x55f3` payload role and its relation to the compact-prefix
   regimes and primary-child restore path.
+- That short trailing lane is tighter now too: direct disassembly of `0x0052ebd0/0x0052ec50`
+  shows the post-`+0x48` helper pair loading and serializing two single-byte lanes that fold into
+  bits `0x20` and `0x40` of `[this+0x20]`, and the save-side probe now shows the dominant
+  `0x06`-byte rows all carrying the same grounded flag pair `0x00/0x00` on `q.gms`. So the next
+  concrete infrastructure question is no longer “is there a short trailing flag lane?”; it is how
+  the compact-prefix regimes and those flag-byte pairs feed the child-count / primary-child restore
+  state above `0x0048dcf0`.
 - 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
@@ -227,6 +234,11 @@ Working rule:
   and sampled row boundaries. That means the next pass can decode the short embedded `0x55f3`
   payload lane on top of already grounded row boundaries instead of rediscovering the same
   envelopes again.
+- That same probe now also exports the grounded short trailing flag-byte pair summary for the
+  dominant `0x06`-byte rows, while the infrastructure trace carries the matching
+  `0x0052ebd0/0x0052ec50` helper seam. That means the next pass can aim directly at how those
+  flags combine with compact-prefix regimes and primary-child restore state instead of treating the
+  short lane as anonymous payload.
 - That same trace now also ranks those consumers into explicit hypotheses, so the next
   infrastructure pass should start with the attach/rebuild strip instead of treating all
   candidate owners as equally likely.