more work done

docs/entity-vm-runtime-owner-resource-layout.md

@@ -72,17 +72,18 @@ Strong anchors:
 
 Best current helper shape:
 
-- compact file-backed helper object
-- helper-owned count at `+0x14`
-- far-pointer table at `+0x10`
-- paired 16-bit table at `+0x18`
-- helper vtable `+0x04` acts as size query
-- helper vtable `+0x0c` materializes the `0x0d`-stride owner rows later consumed by contexts
+- compact `0x14`-byte file-backed wrapper object
+- first `0x08` bytes are the embedded file-handle base initialized by `File_MallocOrInit8Bytes`
+- helper vtable/dispatch pointer lives at `+0x08`
+- materialized owner-row table far pointer lives at `+0x0c`
+- helper vtable `+0x04` acts as the current best size/query callback
+- helper vtable `+0x0c` materializes owner data; the thin wrapper now asserts if the first output byte is `0xff`
 
 Current safest interpretation:
 
 - this is the most bounded class-lift target in the VM lane
 - it looks like a real helper object with a compact stable layout and a clear owner relationship to `EntityVmRuntime`
+- the earlier `+0x14` / `+0x18` count-and-table claims belong to the downstream materialized loader data, not to the outer `0x14`-byte wrapper itself
 
 ### seg070 loader contract
 
@@ -172,9 +173,9 @@ Verified first batch landed in the live `CRUSADER.EXE` session on 2026-04-05.
 
 - Created namespace `Remorse` and class owners `Remorse::EntityVmOwnerResource`, `Remorse::EntityVmRuntime`, and `Remorse::EntityVmContext`.
 - Created provisional datatype `/Remorse/EntityVmOwnerResource` with current stable anchors:
-	- `+0x10 owner_row_table`
-	- `+0x14 entry_count`
-	- `+0x18 entry_word_table`
+	- first `0x08` bytes reserved for the embedded file base
+	- `+0x08 helper_vtable`
+	- `+0x0c owner_row_table`
 - Created provisional datatype `/Remorse/EntityVmRuntime` with size `0x1319` and only the currently stable tail anchors around the owner-resource attachment lane.
 - Created provisional datatype `/Remorse/EntityVmSlotEntry` with size `0x26` and only the currently stable tail buffer fields named:
 	- `+0x1e owner_buffer_offset`
@@ -296,6 +297,11 @@ Verified first batch landed in the live `CRUSADER.EXE` session on 2026-04-05.
 	- `1420:1601 Remorse::EntityVmRuntime::Destroy` -> `byte __cdecl16far Destroy(EntityVmRuntime * this, word destroy_flags)`
 	- `1420:10b6/10da/1162/118f/1278 Remorse::EntityVmContext::{FreeBuffer, SyncGlobalValueAndDispatch, Destroy, Save, Load}` now all carry explicit `EntityVmContext *32 this`
 - That leaves `CreateFromSlotIndex` as the one clearly still-complex VM signature in this family cluster: the body still shows a far `this`, but the remaining argument pack needs a dedicated caller-side recovery pass rather than another pointer-only rewrite.
+- Verified sixteenth live batch landed on 2026-04-08.
+- Re-read `1430:0000 Remorse::EntityVmOwnerResource::Create` and `1430:00fd Destroy` against the live decompiler and corrected the outer-wrapper model: the object itself is only `0x14` bytes, with the first `0x08` bytes acting as the embedded file base, the helper vtable pointer at `+0x08`, and the materialized owner-row table far pointer at `+0x0c`.
+- Moved `1430:014c` under `Remorse::EntityVmOwnerResource` as `MaterializeChecked` after confirming from `InitSlotOwnerBuffers` and `EnsureSlotChunkLoaded` that it is the thin wrapper over helper vtable slot `+0x0c` used to materialize owner data and assert on `0xff` sentinel failure.
+- Moved `1430:0195` under `Remorse::EntityVmOwnerResource` as `QueryMaterializationSize` after confirming it is the adjacent thin wrapper over helper vtable slot `+0x04`, with the current safest read still being the same size/query callback already seen from the `Create` path.
+- Added short decompiler comments at `1430:014c` and `1430:0195` so the callback-slot evidence remains visible in-session without pretending the full seg069/070 helper contract is closed.
 - Verified fifteenth live batch landed on 2026-04-06.
 - Recovered the mixed caller pack on `1420:0eec Remorse::EntityVmContext::CreateFromSlotIndex` far enough to replace the old anonymous split arguments with caller-backed names:
 	- `dword owner_source_farptr`
@@ -317,6 +323,7 @@ Verified first batch landed in the live `CRUSADER.EXE` session on 2026-04-05.
 Current live datatype state:
 
 - `/Remorse/EntityVmOwnerResource` is the cleanest landed class in this lane so far.
+- Its current stable outer-wrapper model is now tighter too: embedded file base at `+0x00..+0x07`, helper vtable at `+0x08`, and materialized owner-row table far pointer at `+0x0c`.
 - `/Remorse/EntityVmRuntime` currently only freezes the stable tail fields and helper pointer, not the full slot-entry schema.
 - `/Remorse/EntityVmSlotEntry` now exists both as a bounded helper datatype and as a live `Remorse` class owner. Its current authored surface is intentionally small: one constructor/clear method plus the stable `match_key_farptr`, `owner_chunk_count`, `owner_data_base`, and owner-buffer / chunk-state pointer anchors.
 - `/Remorse/EntityVmLoadedChunkRecord` now exists as the shared cleanup/iteration record for the chunk-release and conditional-unload lane, with the currently stable next-link, saved-owner-buffer, slot-index, and chunk-index fields named.
@@ -335,7 +342,7 @@ Current live datatype state:
 Current scope of that batch stayed intentionally conservative:
 
 - no final source-format schema naming for the owner rows
-- no speculative promotion of additional seg069/070 helper callbacks into owned methods yet
+- no speculative promotion of additional seg069/070 helper callbacks beyond `QueryMaterializationSize` and `MaterializeChecked`
 - no speculative promotion of the masked-create wrapper ladder into `EntityVmContext` methods
 - no speculative typing yet for the entity-like pointer parameter on `AcquireSlotForEntity`
 - no attempt yet to force slot-entry field names beyond the stable `+0x1e..+0x24` tail region and the current conservative helper prototypes