Ground infrastructure footer-bit consumers

crates/rrt-runtime/src/smp.rs

@@ -4583,6 +4583,7 @@ fn build_infrastructure_asset_trace_report(
                 "objdump on 0x00455b70 now also makes the shared child seed strip concrete: after zeroing the same [this+0x206/+0x20a/+0x20e] lanes, it copies stack args 1/2/3 into them through 0x51d820 whenever those args are non-null, so the 0x490960 call pattern seeds [0x206] from fixed payload literal 0x005c87a8, [0x20a] from the caller stem, and [0x20e] from fixed literal 0x005cfd74 = \"Infrastructure\" before 0x004559d0 later serializes those same three lanes".to_string(),
                 "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(),
                 "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(),
@@ -5489,6 +5490,7 @@ fn build_infrastructure_asset_trace_report(
     let notes = vec![
         "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(),
         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

@@ -217,10 +217,15 @@ Working rule:
   `0x01 / 0x00`, and fixed prior profile span `0x03` in both saves, while
   `0xff0000ff / 0x0001 / 0xff` stays on prelude `0x0001 / 0xff`, fixed short-flag pair
   `0x00 / 0x00`, and widely scattered prior profile spans in both saves.
-- That means the remaining infrastructure question is no longer broad exact-class identity. It is
-  specifically what those two short-flag families mean and why a minority of tunnel rows route
-  into the sparse `0xff0000ff / 0x0001 / 0xff` outlier class instead of the stable
-  `0x000055f3 / 0x0001 / 0xff` tunnel family.
+- Direct consumers of those footer bits are grounded now too: `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
+  `0x00529730` only takes the later `0x530280` follow-on when bit `0x40` in `[child+0x20]` is
+  set.
+- 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.
 - Source-side constructor analysis is narrower now too. `0x00490960` takes:
   - mode at stack arg 1
   - stem at stack arg 2