site: open-iov.org 2026 documentation update

- tools/site: Markdown-to-MediaWiki converter (tracked-paths-only link
  mapping, local-marker scan, About-message insert), WikiBot publisher
  with diff/check modes and publish manifest, live site auditor, image
  uploader, site-only page sources (landing page, About, index, sidebar,
  banner templates, About-message template).
- wiki: new public deep-dive sources (project status, install, FAQ,
  system overview, GSP and GSP-RM, execution frontier, host module,
  guest stack, UVM, physical backend, driver lifecycle, risc-v-gsp-rm-debugger,
  hardware/software matrix, HAAEEP, glossary); refreshed CUDA userspace
  status; corrected cross-document links; README rewritten for the new set.
- wiki/.publish-manifest.json records each published revision for rollback.

1 files changed, 25 insertions, 17 deletions

diff --git a/wiki/CUDA-Userspace-Driver.md b/wiki/CUDA-Userspace-Driver.md
index 3fa5d41..9a041ef 100644
--- a/wiki/CUDA-Userspace-Driver.md
+++ b/wiki/CUDA-Userspace-Driver.md
@@ -1,13 +1,17 @@
 # CUDA Userspace Driver (`libcuda.so`) — Analysis Deep Dive
 
-> **Status (2026-09-23, honest).** The analysis covers the whole library for
+> **Status (2026-10-12, honest).** The analysis covers the whole library for
 > driver 570.144 and the tooling is version-agnostic. The *control plane* gets
-> the stock guest stack through `cuInit`, device enumeration and into
-> `cuCtxCreate`, which is blocked at `rc=999` because the emulated engine list
-> is missing the async copy engine `COPY14`. The *data plane* is at the
-> software memop bridge: the host executes the memsets, copies and semaphore
-> releases it decodes from guest push buffers, and **no CUDA kernel has been
-> forwarded yet**. Canonical detail: [`01-architecture.md`](../userspace/cuda/docs/01-architecture.md)
+> the stock guest stack through `cuInit`, device enumeration, `cuCtxCreate`
+> and the full driver-API smoke test — allocation, copies, free and destroy
+> complete end to end (`ALL OK`; the 64-byte payload round-trips exactly).
+> The *data plane* decodes guest push buffers and executes the memory and
+> semaphore work it understands; CUDA kernel launches are forwarded to the
+> physical execution path, where a launch reaches the engine queue
+> (front-end deposit and scheduling are observed) but an engine-authored
+> release is not yet observed. Green runs are not yet reproducible on every
+> boot — an open issue, tracked in the repository. Canonical detail:
+> [`01-architecture.md`](../userspace/cuda/docs/01-architecture.md)
 > through `08`; reading order
 > [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md);
 > front door [`../docs/README.md`](../docs/README.md).
@@ -166,17 +170,21 @@ the data plane (`docs/08`).
   it — work path abstracted from day one.
 * **Control plane today:** GSP-RM emulation, RPC handling, BAR/PCI/MSI-X
   emulation and object/control replies are implemented; the stock guest stack
-  gets through `cuInit` and device enumeration into `cuCtxCreate`.
-* **Current blocker:** `cuCtxCreate` returns `rc=999` (`CUDA_ERROR_UNKNOWN`)
-  because the class-filtered engine list is missing the async copy engine
-  `COPY14` (descriptor `0x793ceb0e`, instance 14, client type `0x38`, class
-  `0xc9b5`). The oracle list has 7 engines (GR, CE0..CE4, `COPY14`); the guest
-  list has 6. The driver silently skips engines with no per-(class, instance)
-  database entry, then reads a zeroed secondary record and rolls back; what
-  builds that database entry is the open question (`docs/05` §3.6–3.7).
+  completes `cuInit`, device enumeration, `cuCtxCreate` and the driver-API
+  smoke test (allocation, copies, free and destroy).
+* **Current frontier:** a guest CUDA kernel launch is forwarded and reaches
+  the physical engine queue — the front end deposits the launch and the
+  scheduling path accepts it — but the engine does not yet execute the
+  forwarded launch descriptor: an engine-authored release is the only proof
+  of execution and it is not observed. The per-boot green/stall variance on
+  the emulation path is an open issue, tracked in the repository. The chain,
+  the evidence and the live state are on
+  [`Execution-Frontier.md`](Execution-Frontier.md).
 * **Data plane today:** the host module decodes guest push buffers as method
-  streams and **executes the small work it understands itself** — memsets,
-  copies and semaphore releases. **No CUDA kernel has been forwarded yet.**
+  streams and executes the memory and semaphore work it understands
+  (memsets, copies, semaphore releases), and forwards engine-class work to
+  the physical backend; kernel launches are forwarded but not yet executed
+  by the engine.
 
 ## 5. The crash-path lesson: replies are consumed data