Bound external Tier-2 resolver caller

docs/control-loop-atlas/map-and-scenario-content-load.md

@@ -124,6 +124,13 @@
   row `ServiceTower` still has `byte_0xba = 0x00`, `byte_0xbb = 0x00`. So the remaining
   load-side question is no longer whether the exact `0x00419590` strip itself carries the seeded
   nonzero selector; current evidence says it does not.
+  The `0x00419590` caller surface is boxed in further too. Current direct caller recovery still
+  keeps the actual load-side use under the already-grounded `0x00419230` rebank-or-clone strip,
+  while the only newly surfaced non-local caller is `0x00506424`, which reaches `0x00419590` from
+  a live placed-structure consumer path that immediately flows through `0x00402c90` and
+  `0x0040dc40`. So the remaining load-side question is no longer whether `0x00419590` itself is a
+  hidden load-side owner; it is still the earlier seed-row or projection seam that makes later
+  clone/consumer paths see nonzero bank bytes.
   The global stock selector report tightens that further: the full `MachineShop.bca` signature
   (`0x00/0x80/0x3f/0x00` across `0xb8..0xbb`) is unique across the checked-in stock `.bca`
   corpus. So the remaining load-side Tier-2 frontier is one surfaced stock-file outlier plus the

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

@@ -1372,6 +1372,13 @@
   row is `ServiceTower`, and it still carries `byte_0xba = 0x00`, `byte_0xbb = 0x00`. So the
   remaining Tier-2 source question is no longer whether the exact `0x00419590` strip itself
   carries seeded nonzero bank bytes; current evidence says it does not.
+  The `0x00419590` caller surface is boxed in further too. Current direct caller recovery still
+  keeps the real load-side use under the already-grounded `0x00419230` rebank-or-clone strip,
+  while the only newly surfaced non-local caller is `0x00506424`, which reaches `0x00419590` from
+  a live placed-structure consumer path that immediately flows through `0x00402c90` and
+  `0x0040dc40`. So the remaining Tier-2 source question is no longer whether `0x00419590` itself
+  is a hidden load-side owner; it is still the earlier seed-row or projection seam that makes
+  later clone/consumer paths see nonzero bank bytes.
   The global stock `.bca` selector report narrows that again: the exact `MachineShop.bca`
   signature (`byte_0xb8 = 0x00`, `byte_0xb9 = 0x80`, `byte_0xba = 0x3f`, `byte_0xbb = 0x00`) is
   unique across the checked-in stock corpus. So the remaining Tier-2 source frontier is not a

docs/rehost-queue.md

@@ -1332,6 +1332,13 @@ Working rule:
     `byte_0xba = 0x00`, `byte_0xbb = 0x00`. So the remaining Tier-2 question is no longer
     whether the exact `0x00419590` source-family strip itself carries the seeded nonzero bank
     bytes; current evidence says it does not.
+  - the `0x00419590` caller surface is boxed in further too:
+    current direct caller recovery still keeps the real load-side use under the already-grounded
+    `0x00419230` rebank-or-clone strip, while the only newly surfaced non-local caller is
+    `0x00506424`, which reaches `0x00419590` from a live placed-structure consumer path that
+    immediately flows through `0x00402c90` and `0x0040dc40`. So the remaining Tier-2 question is
+    no longer whether `0x00419590` itself is a hidden load-side owner; it is still the earlier
+    seed-row or projection seam that makes later clone/consumer paths see nonzero bank bytes.
   - the global stock `.bca` selector report narrows that one step further still: the exact
     `MachineShop.bca` signature (`byte_0xb8 = 0x00`, `byte_0xb9 = 0x80`, `byte_0xba = 0x3f`,
     `byte_0xbb = 0x00`) is unique across the checked-in stock corpus. So the current Tier-2