docs: engineering-operations playbook and project-wide status accuracy pass

- docs/eng-ops.md gains Part II, live physical-backend engineering
  operations: hard rules, the full module-parameter matrix, the routine
  supervised cycle and clean-release checklist, the debugfs inventory,
  how to read gsp-phys-state, a debugging scenario catalogue
  (CTXNOTVALID/promote wedge, fail-safe WPR2, unload hangs, guest wedges,
  MMU/PTE and PBDMA faults, relay symptoms), a hazard register (crash
  causes and debugging side effects), the physical-backend OODA loop, and
  the work-context map with porting flows
- architecture, implementation, operations, orientation, getting-started,
  portability, ecosystem and reference docs corrected to the current
  state: CUDA driver-API smoke green, CE-class work forwarding and
  engine-authored releases plus fault relay in place (default off), GR
  execution blocked on engine-context validity, the promote wedge and
  designed locked fail-safe, and P5 wave-2 subsumed
- internal-reference cleanup in tracked docs (no analysis-source or
  local-archive references); historical architecture document bannered
- README reading list and STATE-CURRENT frontier refreshed; new pages
  (runbook, green-eye user guide, porting sequence, porting/packaging
  notes) linked from the tree

Link check: scripts/check-docs-links.py passes (56 files, no broken links).

1 files changed, 7 insertions, 5 deletions

diff --git a/docs/03-architecture/01-system-overview.md b/docs/03-architecture/01-system-overview.md
index 5c2ba6c..fa328ae 100644
--- a/docs/03-architecture/01-system-overview.md
+++ b/docs/03-architecture/01-system-overview.md
@@ -60,7 +60,7 @@ HOST MODULE  open-iov-vfio.ko
   ├─ virtual device: config space, BAR0/BAR1/BAR3 windows, MSI-X
   ├─ emulation core: GSP boot + GSP-RM (RPC msgq, controls, objects, events)
   ├─ memory model: guest RAM access, VA↔PA maps, VRAM backing
-  └─ work path: channel/push forwarding to the physical GPU   [goal; software bridge today]
+  └─ work path: channel/push forwarding to the physical GPU   [CE copies forwarded (default off); GR open]
         │ module-owned device + real GSP session
 HOST BACKEND  the GPU's own hardware + GSP firmware, driven by this module
         │     (the distribution nvidia.ko stays unmodified and unbound in
@@ -170,10 +170,12 @@ decompiled and mapped (see `wiki/GSP-570.144W-Firmware-Analysis.md` and
    without server-side object management. Where the driver consumes a reply
    value, that value is still being corrected (the reply-fidelity ladder).
 5. `nvidia-smi -L` enumerates the emulated device and CUDA user-space starts
-   (`cuInit` / `cuDeviceGetCount` / `cuDeviceGet` succeed). The client reaches
-   `cuCtxCreate`, which currently ends in a forced `rc=999` on a completion
-   wait; the copy-engine method streams execute in software as a bridge, and
-   the execution backend is not built yet (see
+   (`cuInit` / `cuDeviceGetCount` / `cuDeviceGet` succeed); context creation
+   completes and the full CUDA driver-API smoke passes (`ALL OK` 64/64, copies
+   matched). The execution backend is live: CE-class copies are
+   forwarded to the physical copy engine (default off) with engine-authored
+   semaphore releases and a fault relay; kernel execution is blocked on GR
+   engine-context validity (see
    [`08-physical-gpu-integration.md`](08-physical-gpu-integration.md)).
 
 The CUDA-side contract and the reply-fidelity rules are documented in