Bound compact event control-lane follow-on builder

This commit is contained in:
Jan Petykiewicz 2026-04-19 02:21:53 -07:00
commit 13e1101156
2 changed files with 23 additions and 0 deletions

View file

@ -357,6 +357,13 @@ Working rule:
strip. So the next non-hook question is not “maybe load inherits trigger kind through
0x0042e050”; it is which other ordinary owner, if any, seeds `[event+0x7ef]` for these
already-decoded non-direct rows.
- the first non-editor positive control-lane writer is bounded away from restore too:
direct disassembly now shows `0x00430b50` allocating a fresh live runtime-effect row through
`0x00432ea0 -> 0x0042d5a0`, zero-initializing the full `[event+0x7ee..0x7fa]` block, then
seeding `[event+0x7ef]` to `2` or `3` plus adjacent control bytes. That builder is reached
from the `0x004323a0` follow-on service strip at `0x0043232e`, not from `0x00433130` restore.
So the remaining ordinary-owner question is narrower again: neither deep-copy inheritance nor
the first positive control-lane builder currently belongs to the non-direct `0x4e9a` load path.
- the positive-path caller census is effectively boxed in now too:
direct `0x0040ef10` callers are the create-side pair `0x00403ef3 / 0x00404489`, the transport
tuple pair `0x0046f073 / 0x004707ff`, and the already-ruled-down live controller