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, 8 insertions, 7 deletions

diff --git a/docs/03-architecture/02-guest-stack-and-cudasw.md b/docs/03-architecture/02-guest-stack-and-cudasw.md
index e841342..f9fe249 100644
--- a/docs/03-architecture/02-guest-stack-and-cudasw.md
+++ b/docs/03-architecture/02-guest-stack-and-cudasw.md
@@ -88,14 +88,15 @@ open /dev/nvidia* → cuInit → UVM registration (per process)
 ```
 
 The initialization path is where compatibility is won or lost; the runtime
-path is where *execution* is won or lost. Open-IOV's current focus is
-pre-forwarding correctness: `cuInit` / `cuDeviceGet` succeed, and the client
-reaches context creation, which currently ends in a forced `rc=999` on a
-completion wait; the engine inventory is complete and the forwarding decision
-is made — a module-owned GPU running its real GSP firmware as the
-resource-manager server (see
+path is where *execution* is won or lost. Context creation and the full CUDA
+driver-API smoke now pass (`ALL OK`, copies matched), so the current focus is
+execution: the forwarding decision is made and the backend is live — a
+module-owned GPU running its real GSP firmware as the resource-manager server
+(see
 [`../../userspace/cuda/docs/08-virtualization-approaches.md`](../../userspace/cuda/docs/08-virtualization-approaches.md)
-and [`08-physical-gpu-integration.md`](08-physical-gpu-integration.md)).
+and [`08-physical-gpu-integration.md`](08-physical-gpu-integration.md)) — with
+CE-class copies forwarded to the physical copy engine (default off) and GR
+kernel execution blocked on GR engine-context validity.
 
 For the CUDA userspace side of this stack — its architecture, how it is built
 and executes, and the exact kernel/GPU interface contract we must satisfy —