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