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

diff --git a/docs/09-reference/glossary-and-faq.md b/docs/09-reference/glossary-and-faq.md
index e0c68f6..1668e35 100644
--- a/docs/09-reference/glossary-and-faq.md
+++ b/docs/09-reference/glossary-and-faq.md
@@ -97,16 +97,24 @@ MIG is a hardware partitioning mechanism; Open-IOV's scheduling policy can use
 it where available. It is part of the multi-tenancy work.
 
 **How fast is it?**
-No published numbers yet: execution forwarding is not implemented, and even
-the initialization path has not been measured under the project's methodology.
-Any performance claim will come with the methodology and the measurements
-together (see
+No published numbers yet: copy-engine-class work forwarding and engine-authored
+release + fault relay are implemented but default off, and GR/kernel execution
+is still the open frontier; even the initialization path has not been measured
+under the project's methodology. Any performance claim will come with the
+methodology and the measurements together (see
 [`../05-operations/01-performance-correctness-security.md`](../05-operations/01-performance-correctness-security.md)).
 
 **Where do I report bugs or ask for help?**
 Open an issue with the standard captures listed in the debugging document. A
 reproduction plus logs is worth more than a description.
 
+**Can I run the live hardware cycles?**
+Live physical-backend cycles are supervised only — one at a time, never
+unattended — and a system is never rebooted without a written reason, a
+post-reboot plan and explicit human approval. The operational detail is in the
+engineering-operations document, Part II
+([`../eng-ops.md`](../eng-ops.md)).
+
 **Can my company use this commercially?**
 Yes, under BSD-3-Clause (kernel modules GPL-2.0), with no fee. We also welcome
 co-development; see the ecosystem document.