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, 10 insertions, 9 deletions

diff --git a/docs/01-orientation/01-purpose-and-scope.md b/docs/01-orientation/01-purpose-and-scope.md
index ff13603..278ad0d 100644
--- a/docs/01-orientation/01-purpose-and-scope.md
+++ b/docs/01-orientation/01-purpose-and-scope.md
@@ -131,15 +131,16 @@ document:
 
 * **Working today**: the virtual device, the GSP boot handshake, the RPC
   transport, the resource-manager emulation surface the guest driver needs to
-  probe and enumerate, guest `nvidia.ko` and `nvidia-smi`, and CUDA user-space
-  startup through `cuInit` / `cuDeviceGet`.
-* **Needs improvement**: reply fidelity and completion translation first —
-  context creation currently ends in a forced `rc=999` on a completion wait,
-  and some consumed reply fields are still generic fallbacks — then GPU work
-  forwarding (the reason CUDA kernels do not yet run; the backend is chosen),
-  the memory/page-table model, Windows guest support,
-  non-KVM hypervisors, and performance instrumentation. Each of these is
-  tracked with explicit "known-unknowns" in
+  probe and enumerate, guest `nvidia.ko` and `nvidia-smi`, and the full CUDA
+  driver-API path through context creation, allocation and verified copies
+  (the driver-API smoke passes).
+* **Needs improvement**: engine execution first — the backend is live and
+  CE-class copies and their releases are forwarded to the physical copy engine
+  (default off) with a fault relay, but CUDA kernel execution is blocked on GR
+  engine-context validity — then the remaining reply fidelity (some consumed
+  fields are still generic fallbacks), the memory/page-table model, Windows
+  guest support, non-KVM hypervisors, and performance instrumentation. Each of
+  these is tracked with explicit "known-unknowns" in
   [`../04-implementation/01-known-knowns-and-unknowns.md`](../04-implementation/01-known-knowns-and-unknowns.md);
   for the CUDA analysis area, start at
   [`../../userspace/cuda/READ-ME-FIRST.md`](../../userspace/cuda/READ-ME-FIRST.md).