Map infrastructure child constructor mode families

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

@@ -3070,6 +3070,19 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
   same child payload fields that `0x004559d0` later serializes. So the remaining infrastructure
   problem is which chooser branches feed `0x00490960` which stem/selector tuples for each
   grounded save-side class, not where the child payload lanes come from at all.
+  One direct branch is grounded now too: the repeated chooser calls at
+  `0x004a2eba/0x004a30f9/0x004a339c` all feed `0x00490960` with mode arg `0x0a` and stem arg
+  `0x005cb138 = BallastCapDT_Cap.3dp`, so they bypass the selector-copy block at `0x004909e2` and
+  go straight into fresh child allocation/seeding. That means the remaining source-side mapping
+  problem is no longer generic BallastCap coverage; it is the other constructor branches,
+  especially the ones with mode `< 4` that actually populate the selector-byte copy block.
+  The broader mode family is grounded now too: a wider static callsite sweep shows mode `0x0b`
+  with fixed `TrackCapDT_Cap.3dp` / `TrackCapST_Cap.3dp`, mode `0x03` with
+  `OverpassST_section.3dp`, mode `0x02` with decoded tunnel table stems plus zero-stem fallbacks,
+  and mode `0x01` with decoded bridge table stems plus zero-stem fallbacks. So the remaining
+  infrastructure problem is no longer “what does `0x00490960` build?” but “how do those grounded
+  mode families collapse into the save-side compact-prefix/name-pair classes, especially the
+  already-grounded bridge-only `0x0002/0xff` class and BallastCap `0x0055/0x00` class?”.
   The smaller attach helper `0x00490a3c` is now bounded too: it conditionally allocates one
   `Infrastructure` child from a caller-supplied payload stem, attaches it to the current owner, and
   then seeds three caller-supplied position lanes through `0x00539530` and `0x0053a5b0`. The