Tighten Tier2 checkpoint sequencing order

artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-sequencing-note.md

@@ -10,6 +10,8 @@ The earlier post-load recipe-runtime rebuild call at `0x00443ebc` runs:
 
 - immediately after the named candidate-availability collection at `[world+0x66b2]`
   has been restored from fixed `0x22`-byte rows
+- by directly calling `0x00435630`
+- then calling `0x00412c10` only if live candidate pool `0x0062b268` is non-null
 - before the neighboring candidate filter/count rebuilds
   `0x00412c10 / 0x00412bd0`
 - before the year-derived follow-ons
@@ -27,11 +29,13 @@ The later explicit `0x197` checkpoint at `0x00444ac1` sits:
 - after the territory-side sweep
   `world_region_border_overlay_emit_segment_geometry_from_region_grid`
   `0x00487de0`
-- and then falls through into
+- and then directly reruns `0x00435630`
+- then falls through into
   `world_preseed_named_candidate_availability_records_from_live_pool`
   `0x00437737`
-- followed by the later candidate-side availability refresh
+- followed by the later unconditional candidate-side availability refresh
   `0x00412c10`
+- and then `0x00434d40`
 
 So the late Tier 2 strip begins with named-availability preseed and latch refresh, not with the
 shell progress or territory overlay helpers that precede it.
@@ -70,4 +74,6 @@ The strongest remaining Tier 2 question is sequencing, not naming:
   `0x00435630 -> 0x00412d70`
   and the broader load-side rebuild owner
   `0x00412fb0`,
+  with the early checkpoint only conditionally refreshing `0x00412c10` but the late checkpoint
+  always rerunning `0x00435630 -> 0x00437737 -> 0x00412c10`,
   rather than on a direct `Warehouse05` availability bit or recipe-book display-name leak.

docs/rehost-queue/tier2-rebuild-sequencing-2026-04-21.md

@@ -51,6 +51,25 @@ The preserved sequencing note keeps the late `0x197` checkpoint concrete too:
 So the late Tier-2 strip begins with named-availability preseed and latch refresh, not with the
 shell progress or territory overlay helpers that precede it.
 
+## Direct Checkpoint Order
+
+Fresh `objdump` over `RT3.exe` now makes the two key bringup checkpoints explicit too:
+
+- early checkpoint `0x00443ebc`
+  - calls `0x00435630`
+  - then calls `0x00412c10` only if live candidate pool `0x0062b268` is non-null
+  - then unconditionally calls `0x00412bd0`
+  - then follows with `0x00434130` and `0x00436af0`
+- late checkpoint `0x00444ac1`
+  - calls `0x00435630`
+  - then immediately calls `0x00437737`
+  - then unconditionally calls `0x00412c10`
+  - then calls `0x00434d40`
+
+So the late bringup strip is not just “somewhere after `0x004354a0`.” It explicitly reruns the
+recipe/runtime rebuild before the named-availability preseed and the later unconditional latch
+refresh.
+
 ## Current Reading
 
 This keeps the active Tier-2 owner question on sequencing and data handoff, not on bare naming:
@@ -59,6 +78,8 @@ This keeps the active Tier-2 owner question on sequencing and data handoff, not
   `0x00435630 -> 0x00412d70 -> 0x00412fb0`
 - the other side is the later named-availability preseed/latch family
   `0x00437737 -> 0x00434f20 -> 0x00412c10`
+- the early checkpoint only refreshes `0x00412c10` when the live candidate pool already exists,
+  while the late checkpoint always reruns `0x00435630 -> 0x00437737 -> 0x00412c10`
 - the remaining non-hook question is how that interaction lets candidate-table rows
   `35/43/45..66` reach `0x00412d70` with nonzero `[candidate+0xba/+0xbb]` before the later
   `0x00419230` rebank-or-clone pass consumes them