docs: refresh status, supersede stale material, link the CUDA analysis

* Status now matches the live state: guest driver probe and nvidia-smi work;
  cuInit/device queries work; cuCtxCreate returns 999 because the emulated
  engine list is missing the async copy engine (COPY14). The userspace
  libcuda segfault is recorded as solved, with its mechanism (an RM
  allocation reply must echo request parameters; zeroing them corrupted the
  caller's saved frame pointer).
* Correct the emulation claims: only a subset of RM controls are
  special-cased; the rest return a success reply with zeroed parameters whose
  consumed fields are still being corrected; allocation replies are coherent
  but no server-side object model exists.
* Add the eight-point emulation checklist and reply-fidelity ladder as
  explicit gates, documented in userspace/cuda and linked from the
  architecture, implementation and operations docs.
* Fix operational errors: build/test commands, module load order, mdev type
  names, LFS references, debugfs claims, in-repo firmware claims, CI claims,
  portability matrix (guest status, config layout, userspace driver facts).
* Mark historical material: one superseded banner per legacy document with a
  pointer to its replacement; STATE.md marked as a 2026-09-21 snapshot.
* Wiki: fix the index, add status banners and in-place factual corrections
  (msgq transport vs legacy mailbox, BAR definitions, error statuses,
  migration, glossary), and note the archived 2023 imports.

1 files changed, 11 insertions, 0 deletions

diff --git a/docs/03-architecture/05-gmmu-amap-hal-gr.md b/docs/03-architecture/05-gmmu-amap-hal-gr.md
index 6ff9257..6111f54 100644
--- a/docs/03-architecture/05-gmmu-amap-hal-gr.md
+++ b/docs/03-architecture/05-gmmu-amap-hal-gr.md
@@ -182,6 +182,17 @@ Engine types are enumerated by the client during init (`FIFO_GET_DEVICE_INFO_TAB
 and reported in engine/capability queries. A guest's channel is bound to one
 engine type (e.g. `COPY0 = 0x9`, `GR = 0x1`).
 
+**Engine inventory is a correctness surface, not just data.** The userspace
+driver builds its per-engine records from the device/engine information the
+kernel driver reports, and filters them against the class list; a missing or
+zeroed record is not ignored - it becomes an allocation with class `0` and the
+whole context setup rolls back. The current CUDA bring-up blocker is exactly
+this: the async copy engine (COPY14, engine descriptor `0x793ceb0e`, instance
+14) is absent from the emulated engine list, while a bare-metal oracle reports
+it as the seventh engine alongside GR and CE0..4. See
+[`../../userspace/cuda/docs/05-570.144-decompilation.md`](../../userspace/cuda/docs/05-570.144-decompilation.md)
+section 3.7 for the record layout the driver's engine walker consumes.
+
 ## 7. Practical reading list inside this repository
 
 | Topic | Where |