Narrow region restore continuation candidates

docs/rehost-queue.md

@@ -608,6 +608,19 @@ Working rule:
   `[this+0x20]`, `[this+0x8d]`, `[this+0x5c..+0x61]`, `[this+0x1ee]`, `[this+0x1fa]`, and
   `[this+0x3e]`, and then it opens `0x55f3` only for span accounting before returning. So the
   missing region latches are not hiding in the remainder of `0x00455fc0` either.
+- The next restore-handoff strip is explicit now too: the region trace now carries a dedicated
+  later-global-restore hypothesis for `0x00444887`, because that continuation is the first caller
+  checkpoint above the ruled-down `0x00421510 -> 0x0041f5c0 -> 0x00455fc0` path. It immediately
+  advances into `0x00487c20` territory refresh and `0x0040b5d0` support refresh, then later
+  re-enters the per-region follow-on loop at `0x00444b90 -> 0x00420560`. Current disassembly keeps
+  `0x00420560` on `[region+0x312]` / `[region+0x317/+0x31b]` only, so the next region pass should
+  treat the broader `0x00444887` continuation as the live handoff seam when chasing
+  `[region+0x2a4]` and `[region+0x310/+0x338/+0x360]`, not as just another generic restore note.
+- That same continuation is slightly less symmetric now too: the atlas-backed territory side at
+  `0x00487c20` currently restores only collection metadata/live ids and still uses no-op per-entry
+  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 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