Link infrastructure footer gate to presentation owner

crates/rrt-runtime/src/smp.rs

@@ -4584,6 +4584,7 @@ fn build_infrastructure_asset_trace_report(
                 "objdump on 0x51d820 now also shows those seeded lanes are owned heap strings, not encoded ids: it frees any prior pointer through 0x5a1145, counts the incoming NUL-terminated ASCII bytes, allocates a fresh buffer through 0x5a125d, and copies the source string byte-for-byte into the destination slot".to_string(),
                 "objdump on 0x52ec50 now also makes the short footer bytes literal: it serializes one byte from bit 5 of [this+0x20] and one byte from bit 6 of [this+0x20] through 0x531030, so the residual compact-prefix ambiguity still lives in how those footer bits compose with the next-record prelude rather than in the seeded name lanes themselves".to_string(),
                 "direct disassembly now also grounds one concrete consumer strip below those footer bits: 0x00528d90 only admits the child when the explicit caller override is set, the surrounding global override byte [owner+0x3692] is set, or bit 0x20 in [child+0x20] is set; the sibling loop at 0x00529730 only takes the later 0x530280 follow-on when bit 0x40 in [child+0x20] is set".to_string(),
+                "that footer-bit consumer strip is tied to a broader higher-layer owner family now too: the same 0x005295f0..0x005297b7 loop repopulates a candidate cell set through 0x00533ba0, walks candidate child lists through 0x00556ef0/0x00556f00, and honors the same controller mode byte [owner+0x3692] that the checked-in atlas already ties to the world-window presentation dispatcher. So the remaining bit-0x20 question belongs to that nearby-presentation/controller family rather than to a free-floating serializer flag".to_string(),
                 "objdump on 0x531030/0x5a464d/0x5a44a8 now also shows the infrastructure writer is not hiding another per-owner transform there: 0x531030 just forwards the caller-supplied pointer and byte count into the generic stream backend, and 0x5a44a8 is the shared chunked stream write path keyed by the stream handle rather than an infrastructure-specific encoder".to_string(),
                 "that caller-matrix split now rules out one easy explanation for the mixed save-side prefixes: the shared 0xff0000ff/0x0001/0xff class cannot come from selector-copy state alone, because its dominant TrackCap rows come from mode-0x0b callers that bypass selector-copy entirely while the tunnel residue comes from mode-0x02 callers that necessarily flow through it".to_string(),
                 "the current grounded q.gms side-buffer name corpus now maps directly onto those constructor families too: BridgeSTWood_Section.3dp aligns with mode 0x01 Bridge, TunnelSTBrick_Cap/Section.3dp with mode 0x02 Tunnel, BallastCapST_Cap.3dp with mode 0x0a BallastCap, and TrackCapST_Cap.3dp with mode 0x0b TrackCap; only the Overpass mode-0x03 family remains static-only in the current save corpus".to_string(),
@@ -5491,6 +5492,7 @@ fn build_infrastructure_asset_trace_report(
         "Infrastructure asset trace now makes the side-buffer-versus-triplet split explicit: owner seam identity is grounded, the pure bridge-only 0x0002/0xff candidate class is grounded save-side, the upstream chooser above the child attach path is grounded as paired DT/ST siblings at 0x004a2c80 and 0x004a34e0 with decoded Bridge/Tunnel/BallastCap/Overpass families, grounded top-level branch meaning, grounded bridge/tunnel material selector roles, a concrete child-construction/write-side chain through 0x00490960, 0x00491c60, 0x0048a6c0, 0x00455a40, and 0x004559d0, and stable 0x00490960 mode families for BallastCap, TrackCap, Overpass, Tunnel, and Bridge branches. The current save-side name corpus already maps BallastCap, TrackCap, Tunnel, and Bridge rows onto those families directly, the candidate-pattern correlation narrows the dominant mixed 0x0001/0xff class to bridge:62 / track_cap:21 / tunnel:19, and the exact compact-prefix correlation now splits the full prelude corpus into mostly pure classes: 0xff0000ff/0x0002/0xff is pure bridge, 0xff000000/{0x0001,0x0002}/0xff are pure bridge, 0xf3010100/0x0055/0x00 is pure ballast-cap, and 0x0005d368/0x0001/0xff is pure track-cap, leaving only 0xff0000ff/0x0001/0xff and 0x000055f3/0x0001/0xff as the mixed residual classes.".to_string(),
         "Cross-save q/p traces now also split those two mixed residual classes by footer and span behavior: 0x000055f3/0x0001/0xff always carries short-flag pair 0x01/0x00 on a fixed span-0x03 tunnel-dominant family, while 0xff0000ff/0x0001/0xff always carries short-flag pair 0x00/0x00 on the scattered-span TrackCap-dominant outlier family. The remaining unknown is therefore the meaning of those short-flag families and the sparse branch that routes a minority of tunnel rows into the 0xff0000ff outlier class.".to_string(),
         "Direct consumers of those footer bits are grounded now too: bit 0x20 of [child+0x20] is the admission gate into the 0x00528d90 branch when no caller/global override is present, while bit 0x40 only feeds the later 0x00529730 -> 0x530280 follow-on. Since both mixed residual classes keep the second footer byte at zero in q/p, the remaining split is now specifically the first footer byte / bit-0x20 gate rather than both footer bytes.".to_string(),
+        "That bit-0x20 gate is no longer floating without context either: the 0x005295f0..0x005297b7 consumer strip repopulates candidate cells through 0x00533ba0, walks child lists through 0x00556ef0/0x00556f00, and honors the same controller mode byte [owner+0x3692] that the atlas already places under the world-window presentation dispatcher. The next infrastructure pass should therefore treat the remaining bit-0x20 question as a nearby-presentation/controller owner problem, not as a serializer-only problem.".to_string(),
         if st_only_name_pair_corpus {
             "The current save-side side-buffer corpus is ST-only, so this trace directly exercises the ST chooser sibling while the DT sibling remains grounded statically but unexercised in this save.".to_string()
         } else {

docs/rehost-queue.md

@@ -222,10 +222,15 @@ Working rule:
   `[owner+0x3692]` is set, or bit `0x20` in `[child+0x20]` is set; the sibling loop
   `0x00529730` only takes the later `0x530280` follow-on when bit `0x40` in `[child+0x20]` is
   set.
+- That footer-bit consumer strip is tied to a broader higher-layer owner family now too:
+  `0x005295f0..0x005297b7` repopulates candidate cells through `0x00533ba0`, walks candidate
+  child lists through `0x00556ef0/0x00556f00`, and honors the same controller mode byte
+  `[owner+0x3692]` that the atlas already places under the world-window presentation dispatcher.
 - That means the remaining infrastructure question is no longer both footer bytes. It is
   specifically why the stable `0x000055f3 / 0x0001 / 0xff` tunnel family sets the first footer
   byte / bit-`0x20` admission gate while the sparse `0xff0000ff / 0x0001 / 0xff` outlier class
-  clears it.
+  clears it, inside that nearby-presentation/controller owner family rather than at the serializer
+  layer.
 - Source-side constructor analysis is narrower now too. `0x00490960` takes:
   - mode at stack arg 1
   - stem at stack arg 2