Preserve Tier2 subtype mark pass sequencing

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

@@ -23,9 +23,9 @@ owners form one coupled strip:
   - also re-enters `0x00411ce0` and `0x00411ee0`
 - `0x00412fb0`
   - broader collection-load owner
-  - re-enters `0x004120b0`
-  - then `0x00412d70`
-  - then `0x00412ab0`
+  - directly loops through the stock/import stream via `0x004120b0`
+  - then calls `0x00412d70`
+  - then calls `0x00412ab0`
   - and only after the later catalog rebuild re-enters `0x00412c10`
 - `0x00437737`
   - late preseed of named candidate-availability records from the live pool
@@ -36,6 +36,9 @@ owners form one coupled strip:
 - `0x00412c10`
   - refreshes `[candidate+0x7ac]` from named availability
   - then tails into `0x0041eac0`
+- `0x00434d40`
+  - late post-refresh sweep over collection `0x0062b26c`
+  - sets `[entry+0x7b0] = 1` for subtype-`2` rows
 
 ## Late Bringup Placement
 
@@ -68,7 +71,7 @@ Fresh `objdump` over `RT3.exe` now makes the two key bringup checkpoints explici
 
 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.
+refresh, and then runs one final subtype-`2` mark pass through `0x00434d40`.
 
 ## Current Reading
 
@@ -80,6 +83,8 @@ This keeps the active Tier-2 owner question on sequencing and data handoff, not
   `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 same late checkpoint then follows with `0x00434d40`, which walks `0x0062b26c` and stamps
+  `[entry+0x7b0] = 1` on subtype-`2` rows
 - 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