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, 4 deletions

diff --git a/docs/03-architecture/03-gsp-and-gsp-rm.md b/docs/03-architecture/03-gsp-and-gsp-rm.md
index 7f206ba..10e6a73 100644
--- a/docs/03-architecture/03-gsp-and-gsp-rm.md
+++ b/docs/03-architecture/03-gsp-and-gsp-rm.md
@@ -59,8 +59,10 @@ firmware: FWSEC raised WPR2 with a zero FRTS error code, the SEC2 booter halted
 with mailbox0 = 0, the RISC-V core reported active (`RISCV_STATUS=0x00000035`,
 active bit 0) and `FALCON_OS` read 0. The server's first message was then a
 status-queue event, function `0x1002` (`NV_VGPU_MSG_EVENT_GSP_RUN_CPU_SEQUENCER`,
-`rpc_result=0`), carrying a command buffer the host must execute;
-`GSP_INIT_DONE` (`0x1001`) follows only after that sequencer runs. The
+`rpc_result=0`), carrying a command buffer the host must execute. Once that
+sequencer runs, `GSP_INIT_DONE` (`0x1001`) is delivered with `rpc_result=0`,
+the static-configuration reply is served from the observed device tables, and
+the session remains live until the unload RPC releases it at teardown. The
 host-side queue pair behind the exchange is one shared page table plus a 256 KB
 command queue and a 256 KB status queue of 4 KB elements.
 
@@ -229,8 +231,10 @@ is not lost.
 The engine-inventory row was the CUDA blocker at the time of writing:
 `libcuda` filters the engine list it receives against the class list and
 expects the async copy engine to be present, because the secondary (async)
-engine record is otherwise zeroed. That inventory is now complete; the
-context-creation wait is later, in the completion path. See
+engine record is otherwise zeroed. That inventory is now complete and context
+creation passes; the current frontier is engine execution, where CE-class
+copies are forwarded to the physical copy engine (default off) and GR kernel
+execution is blocked on GR engine-context validity. See
 [`../../userspace/cuda/docs/05-570.144-decompilation.md`](../../userspace/cuda/docs/05-570.144-decompilation.md)
 section 3.7 for the offsets and the consumed fields, and
 [`../../userspace/cuda/docs/03-driver-and-gpu-interface.md`](../../userspace/cuda/docs/03-driver-and-gpu-interface.md)