Bias region handoff away from support counters

crates/rrt-runtime/src/smp.rs

@@ -5039,13 +5039,14 @@ fn build_region_service_trace_report(
             evidence: vec![
                 "the checked-in region trace already grounds 0x00444887 as the first caller-side checkpoint above 0x00421510: it refreshes the region collection and then immediately advances into the territory and support collection refresh owners".to_string(),
                 "the neighboring atlas-backed restore symmetry already rules the territory side down somewhat too: 0x00487c20 only restores the live territory collection metadata/id family and its current per-entry slots 0x00487670/0x00487680 are still no-op load/save callbacks, so the territory leg now looks less likely than support or a later region-local rebuild to hide [region+0x2a4] or [region+0x310/+0x338/+0x360]".to_string(),
+                "the atlas-backed support seam is broader than a direct region payload owner too: 0x0040b5d0 sits over collection 0x0062b244, whose grounded live owners maintain goose-entry counters and neighboring world support lanes [world+0x4c9a/+0x4c9e/+0x4ca6/+0x4caa] plus selected support-entry state rather than an obvious per-region acquisition latch family".to_string(),
                 "the same grounded evidence already narrows the later per-region follow-on too: 0x00444b90 dispatches 0x00420560 over each live region after the broader restore continuation has already advanced".to_string(),
                 "direct disassembly already rules that per-region follow-on down as a latch owner: 0x00420560 only zeroes and recomputes [region+0x312] from the embedded profile collection [region+0x37f]/[region+0x383] and lazily seeds the year-driven [region+0x317/+0x31b] band through 0x00420350, not [region+0x276/+0x302/+0x316]".to_string(),
                 "that leaves the broader 0x00444887 continuation as the next structured restore seam above the ruled-down 0x00421510 -> 0x0041f5c0 -> 0x00455fc0 path when chasing acquisition-side lanes [region+0x2a4] and [region+0x310/+0x338/+0x360]".to_string(),
             ],
             blockers: vec![
                 "the concrete later-global restore owner that rehydrates [region+0x2a4] and [region+0x310/+0x338/+0x360] is still not grounded below the 0x00444887 continuation".to_string(),
-                "support collection refresh 0x0040b5d0 and the later region-local rebuild remain the strongest adjacent prerequisites now that territory refresh 0x00487c20 is partly ruled down as metadata/id-only".to_string(),
+                "the later region-local rebuild now looks stronger than territory refresh 0x00487c20 or the broader support seam 0x0040b5d0, but the exact restore owner below the 0x00444887 continuation is still not grounded".to_string(),
             ],
         },
         SmpServiceConsumerHypothesis {

docs/rehost-queue.md

@@ -621,6 +621,13 @@ Working rule:
   load/save callbacks `0x00487670/0x00487680`, so the next pass should bias more heavily toward
   support refresh `0x0040b5d0` or the later region-local rebuild than toward territory payload as
   the hidden source of `[region+0x2a4]` and `[region+0x310/+0x338/+0x360]`.
+- The support side is less opaque now too: the same atlas already bounds `0x0040b5d0` above
+  support collection `0x0062b244`, whose grounded live owners maintain goose-entry counters,
+  neighboring world support lanes `[world+0x4c9a/+0x4c9e/+0x4ca6/+0x4caa]`, and selected
+  support-entry state rather than an obvious per-region acquisition latch family. So the next pass
+  should now bias even more toward the later region-local rebuild beneath the `0x00444887`
+  continuation, while still keeping `0x0040b5d0` as a weaker adjacent prerequisite rather than
+  treating it as the primary hidden owner.
 - The later restore-side region owners are narrowed further now too: the `0x00421ce0 ->
   0x0041fb00 -> 0x00421730` sweep is class-`0` raster/id rebuild, `0x004881b0` is a companion
   region-set cell-count rebuild over `[region+0x3d/+0x41]`, `0x00487de0` is a border-segment