Keep the arch layer's prose consumer-agnostic; note the x86-64 binding

The generic address-space layer no longer names win32 in its comments: the
khalf_score and gva_translate doc-comments described themselves in terms of
their current Windows consumer, a downward coupling from the stable layer to a
specific, swappable one. Reworded to describe what each primitive does, not who
calls it. Also drop a dangling reference to the renamed engine handle.

State the contract's real scope in memmodel.h: OS-agnostic but architecture-
bound. The address-space key is the x86-64 CR3 (the PML4 base), shared by any
guest OS on x86-64 - CR3 is an ISA register, not a Windows concept; only its
per-process storage (DirectoryTableBase) is win32-specific and stays in the
win32 engine.

include/memmodel.h

@@ -1,4 +1,4 @@
-/* memmodel.h - the OS-agnostic memory-model contract (the middle layer).
+/* memmodel.h - the OS-agnostic, x86-64 memory-model contract (the middle layer).
  *
  * This is the shared vocabulary between the ENGINE (which turns guest-physical
  * RAM into a usable virtual memory model via x86-64 paging + Windows bring-up)
@@ -6,9 +6,13 @@
  * concept: a handler compiled against this header literally cannot mention an
  * _EPROCESS, a PEB, or an LDR entry.
  *
+ * OS-agnostic, but architecture-bound: the address-space key is the x86-64 CR3
+ * (the PML4 base), shared by any guest OS on x86-64 - it is not portable to an
+ * ISA with a different paging root (e.g. ARM64 TTBR0/1).
+ *
  * Everything here is keyed by a `vmie_mem*` (the opaque physical/paging
- * substrate) plus a `cr3` (the address space). The engine handle `vmie` is
- * never handed to a handler - only `vmie_mem*` + `cr3`.
+ * substrate) plus a `cr3` (the address space). The engine handle is never
+ * handed to a handler - only `vmie_mem*` + `cr3`.
  *
  * Conventions:
  *   - `cr3` is a raw CR3 / DirectoryTableBase value; low flag bits are masked