Tighten region payload callback semantics

This commit is contained in:
Jan Petykiewicz 2026-04-18 19:20:53 -07:00
commit 5bc7b3090e
2 changed files with 6 additions and 3 deletions

View file

@ -537,8 +537,11 @@ Working rule:
- Direct disassembly now closes that callback identity too: `0x0041f590/0x0041f5b0` prove the
world-region vtable root is `0x005c9a28`, so the `0x00455fc0` dispatch at slot `+0x48` lands on
`0x00455870` and the serializer sibling at `+0x4c` lands on `0x00455930`. Those two callbacks
only restore and serialize two triplet-like three-lane scalar bands through
`0x00531150/0x00531030` plus `0x00530720/0x0052e8b0`; they still do not touch
only restore and serialize two helper-local three-lane scalar bands: `0x00455870` reads six
dwords through `0x00531150` and forwards them to `0x00530720 -> [helper+0x1e2/+0x1e6/+0x1ea]`
and `0x0052e8b0 -> [helper+0x4b/+0x4f/+0x53]`, while `0x00455930` writes that same pair back
through `0x00531030`; they still do not touch acquisition-side lanes
`[region+0x2a4]` or `[region+0x310/+0x338/+0x360]`, and they still do not touch
`[region+0x276/+0x302/+0x316]`. That means the remaining region restore target is now the later
owner that rebuilds those latches or the separate tagged body seam that persists them.
- The rest of `0x00455fc0` is ruled down further now too: after the `+0x48` callback it only runs