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, 27 insertions, 6 deletions

diff --git a/docs/03-architecture/07-driver-lifecycle-field-guide.md b/docs/03-architecture/07-driver-lifecycle-field-guide.md
index 8d80694..9de5edb 100644
--- a/docs/03-architecture/07-driver-lifecycle-field-guide.md
+++ b/docs/03-architecture/07-driver-lifecycle-field-guide.md
@@ -88,7 +88,9 @@ gsp-resman-vfio: queue args sharedPA=... ptes=... cmdOff=... statOff=...
 ## 5. Resource-manager initialization (the control battery)
 
 **Guest:** sends `GSP_RM_CONTROL` (76) for every subsystem it initializes.
-Representative controls (all observed, all answered with correct shapes):
+Of the ~160 observed control IDs, 23 are special-cased and answered with real
+values; the rest are answered with a generic `SUCCESS` and zeroed params (the
+fallback). Representative controls:
 
 | Control | Meaning | What matters |
 |---|---|---|
@@ -103,8 +105,11 @@ Representative controls (all observed, all answered with correct shapes):
 | `0x20802a02` | CE PCE mask | one bit per engine |
 | `0x20802a08` | CE fault method buffer size | method buffer sizing |
 | `0x90f10106` | vaspace reserved-PDE contract | **carries page-table physical addresses** (see GSP-RM doc) |
-| `0x20803039` | NVLink masks/VBIOS info | unpopulated but must be shaped |
-| `0x20800a70` | BUS flush with sysmembar | UVM issues these frequently; success suffices |
+| `0x20800123` / `0x20800170` | `GPU_GET_ENGINES` / `GET_ENGINES_V2` | engine inventory (filtered by the class list / classDB); values are consumed — the guest must see the full engine list, including the async copy engine (`COPY14`), and the current `rc=999` blocker lives here |
+| `0x800201` | `GPU_GET_CLASSLIST` | class list (classDB); must agree with the engine list and the CE caps controls |
+| `0x2080012b` | GPU_PROMOTE_CTX (560-byte params) | issued immediately before context creation; fallback generic `SUCCESS`, consumed fields not yet coherent |
+| `0x20803039` | NVLink masks/VBIOS info | fallback: generic `SUCCESS` with zeroed params |
+| `0x20800a70` | BUS flush with sysmembar | fallback: generic `SUCCESS` with zeroed params; UVM issues these frequently |
 
 **Log signature:**
 ```
@@ -125,8 +130,15 @@ CUDA process:
 0xc46f     TURING_CHANNEL_GPFIFO_A(368 bytes) ← the channel (GPFIFO VA, instance/userd descriptors)
 0xc076     GP100_UVM_SW           (0 bytes)
 0xc5b5     TURING_DMA_COPY_A      (8 bytes)   ← CE object
+0xc5c0     TURING_COMPUTE_A       (16 bytes)  ← compute object (engine registration path)
 ```
 
+The `TURING_COMPUTE_A` (0xc5c0) alloc is where the earlier `libcuda` segfault
+was fixed: the caller issues it with `paramsSize=0` against an 8-byte stack
+local while the kernel side treats the class params as 16 bytes and copies the
+reply params back, so the emulation must echo the request params back in the
+alloc reply instead of writing a reply the caller did not ask for.
+
 Channel parameters decode into: `gpFifoOffset` (a GPU VA),
 `gpFifoEntries`, `engineType` (e.g. COPY0 = 0x9), and
 `NV_MEMORY_DESC_PARAMS` for instance/userd/ramfc/method buffers with
@@ -149,9 +161,18 @@ page-tree init.
 **Device must:** let UVM's channels initialize (each channel does a first push
 and waits on a semaphore), and let page-tree initialization proceed.
 
-**Emulation (today):** we can decode the pushes UVM generates and complete
-their semaphore releases by translating the semaphore VA to a guest physical
-address (see the UVM and host-module docs). This is the live development front.
+**Emulation (today):** we can decode the pushes UVM generates and execute
+their memsets, copies and semaphore releases in software by translating the
+semaphore VA to a guest physical address (see the UVM and host-module docs).
+This is a bridge, not forwarding: no work reaches the physical GPU yet.
+
+**Live development front (2026-09-23):** CUDA context creation — `cuCtxCreate`
+returns `rc=999` (`CUDA_ERROR_UNKNOWN`) because the emulated engine list lacks
+the async copy engine (`COPY14`). The engine-record layout and the alloc
+reply-fidelity checks are the first things to inspect
+([`../../userspace/cuda/docs/05-570.144-decompilation.md` §3.3/§3.6](../../userspace/cuda/docs/05-570.144-decompilation.md);
+start at
+[`../../userspace/cuda/READ-ME-FIRST.md`](../../userspace/cuda/READ-ME-FIRST.md)).
 
 **Log signatures (guest side):**
 ```