Rule down post-load region placement branches

This commit is contained in:
Jan Petykiewicz 2026-04-19 12:43:07 -07:00
commit a56d360a3e
4 changed files with 44 additions and 0 deletions

View file

@ -1565,6 +1565,16 @@ Working rule:
`[region+0x27a/+0x27e/+0x282/+0x286]`. So the next non-hook region work should start from the
post-load `319` placed-structure replay seam and only then revisit the narrower region-side
`320/321` branches if the exact field bridge is still missing.
- The `320` branch is narrower than that headline now too: direct worker recovery shows
`0x004235c0` staying inside the live region demand-and-placement family by routing through
`0x00422900` cached category accumulation, `0x004234e0` projected structure-count scalars,
`0x00422be0` placed-count subtraction, and `0x00422ee0` placement attempts over the live
placed-structure registry `0x0062b26c`. That keeps it on live setup and maintenance work rather
than any restore-time republisher for `[region+0x2a4]` or `[region+0x310/+0x338/+0x360]`.
- The `321` branch is narrower in the same way: `0x00437b20` only stages the fast-forward burst,
then re-enters the live region collection through `0x00423d30`, and that helper only republishes
`[region+0x27a/+0x27e/+0x282/+0x286]` via `0x00422900`. It should stay ruled down as a cached
summary refresh instead of a plausible owner for the missing restore-side body lanes.
- 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