Tighten Tier2 checkpoint sequencing order

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