docs: record physical-GPU integration mechanism and refresh project status

- add docs/03-architecture/08-physical-gpu-integration.md: interfaces that
  exist, mechanism options A-E, chosen path (module-owned GPU driven through
  its real GSP firmware), sharing policy, decision record
- update 06-host-module-and-hybrid-model, 02-practical-challenges, system
  overview, known-knowns, docs/README reading order and CUDA-side docs to
  match
- correct stale engine-topology/COPY14 blocker claims across the tree
- add STATE-CURRENT.md as the dated public status snapshot

1 files changed, 24 insertions, 21 deletions

diff --git a/docs/README.md b/docs/README.md
index ed0f206..24b2a21 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -90,31 +90,33 @@ and [`01-orientation/02-the-ai-edge-and-ecosystem.md`](01-orientation/02-the-ai-
 
 ## 3. Where is the project today?
 
-**Honest status (2026-09-23):**
+**Honest status (2026-09-29):**
 
 | Area | State |
 |------|-------|
 | Emulated vGPU device (PCI, BARs, MSI-X, VFIO mdev) | ✅ Working |
 | GSP boot emulation (FWSEC/booter/RISCV handshake) | ✅ Working |
 | GSP-RM message queue + RPC transport | ✅ Working |
-| GSP-RM controls: device/fb/bus tables, CE caps, vaspace, GMMU static info | 🟡 Mostly — values are coherent for the special-cased controls; engine inventory/class-list consistency is the current CUDA blocker (COPY14) |
+| GSP-RM controls: device/fb/bus tables, CE caps, vaspace, GMMU static info | 🟡 Mostly — the engine inventory now includes the async copy engine and the CE capabilities match the device; reply fidelity for the remaining consumed fields is still being tightened |
 | Guest `nvidia.ko` probe, `nvidia-smi` | ✅ Working (TU104) |
-| Guest CUDA driver (`libcuda`) startup | 🟡 Partially — `cuInit`/device enumeration work; `cuCtxCreate` returns `999` (`CUDA_ERROR_UNKNOWN`) because the emulated engine list is missing the async copy engine (COPY14). See [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md) and [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) |
-| CUDA kernel execution | 🔴 Not yet — context creation must succeed first; then GPU work forwarding (today only decoded memsets/copies/semaphore releases execute, in the host) |
+| Guest CUDA driver (`libcuda`) startup | 🟡 Partially — `cuInit` and device enumeration work; the client reaches `cuCtxCreate` and currently ends in a forced `999` on a completion wait while the completion/translation plumbing is made reliable. See [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md) and [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) |
+| CUDA kernel execution | 🔴 Not yet — context creation must complete first, then real work forwarding; the execution backend is chosen but not started ([`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md)); today only decoded memsets/copies/semaphore releases execute, in the host |
 | OpenGL / Vulkan | 🔴 Not yet |
 | Windows guest | 🔴 Not yet |
 | Multi-tenant isolation (VFs, mdev-per-VM) | 🟡 Designed, partially implemented |
 
 We also know exactly where the CUDA bring-up stands and what the next step is:
 the userspace `libcuda` segfault was fixed (an RM allocation reply now echoes
-the request parameters instead of returning zeros), and the remaining blocker
-is data: the engine list the emulation reports must include the async copy
-engine and stay consistent with the class list, because `libcuda` filters
-engines against it. The full mechanism, with offsets and the decompiled call
-path, is in [`../userspace/cuda/docs/05-570.144-decompilation.md`](../userspace/cuda/docs/05-570.144-decompilation.md).
+the request parameters instead of returning zeros), the engine inventory is
+complete, and the client reaches context creation, which currently ends on a
+completion wait while decoded work is made to execute reliably. The full
+mechanism, with offsets and the decompiled call path, is in
+[`../userspace/cuda/docs/05-570.144-decompilation.md`](../userspace/cuda/docs/05-570.144-decompilation.md).
 Beyond that, the missing piece for kernel execution is forwarding the guest's
 *work* (push buffers, page trees, execution) to the physical GPU under our
-control; see [`04-implementation/02-practical-challenges-and-adversarial-interop.md`](04-implementation/02-practical-challenges-and-adversarial-interop.md).
+control; the chosen backend — a module-owned GPU running its real GSP firmware
+as the resource-manager server — is specified in
+[`03-architecture/08-physical-gpu-integration.md`](03-architecture/08-physical-gpu-integration.md).
 
 ## 4. How to read these docs (progressive disclosure)
 
@@ -123,9 +125,9 @@ Read in order if you are new. Jump directly if you know what you need.
 > **Debugging the CUDA bring-up?** Start with
 > [`../userspace/cuda/READ-ME-FIRST.md`](../userspace/cuda/READ-ME-FIRST.md) —
 > a five-minute guide to the userspace driver analysis, the corrected crash
-> path, the current engine-topology blocker, and the lookup recipes for
-> `libcuda+0x...` offsets. It links back into this tree for the interface and
-> emulation contract.
+> path, the current completion frontier and the chosen execution backend, and
+> the lookup recipes for `libcuda+0x...` offsets. It links back into this tree
+> for the interface and emulation contract.
 
 | # | Document | Audience | Time |
 |---|----------|----------|------|
@@ -139,14 +141,15 @@ Read in order if you are new. Jump directly if you know what you need.
 | 8 | [GMMU, AMAPlib, HALs, runlist, GR](03-architecture/05-gmmu-amap-hal-gr.md) | developers | 25 min |
 | 9 | [Host module and hybrid model](03-architecture/06-host-module-and-hybrid-model.md) | developers | 25 min |
 | 10 | [Driver lifecycle field guide](03-architecture/07-driver-lifecycle-field-guide.md) | developers, debuggers | 30 min |
-| 11 | [Known-knowns and known-unknowns](04-implementation/01-known-knowns-and-unknowns.md) | everyone technical | 25 min |
-| 12 | [Practical challenges and adversarial interoperability](04-implementation/02-practical-challenges-and-adversarial-interop.md) | developers, stakeholders | 20 min |
-| 13 | [Performance, correctness, security](05-operations/01-performance-correctness-security.md) | developers, auditors | 25 min |
-| 14 | [Debugging and maintenance workflows](05-operations/02-debugging-and-maintenance-workflows.md) | developers, maintainers | 25 min |
-| 15 | [Hardware and software matrix](06-portability/hardware-software-matrix.md) | developers, integrators | 20 min |
-| 16 | [Developer onboarding and standards](07-developers/onboarding-and-standards.md) | contributors | 20 min |
-| 17 | [HAAEEP and collaboration](08-ecosystem/haaeep-and-collaboration.md) | stakeholders, partners | 20 min |
-| 18 | [Glossary and FAQ](09-reference/glossary-and-faq.md) | everyone | reference |
+| 11 | [Physical GPU integration](03-architecture/08-physical-gpu-integration.md) | developers, architects | 20 min |
+| 12 | [Known-knowns and known-unknowns](04-implementation/01-known-knowns-and-unknowns.md) | everyone technical | 25 min |
+| 13 | [Practical challenges and adversarial interoperability](04-implementation/02-practical-challenges-and-adversarial-interop.md) | developers, stakeholders | 20 min |
+| 14 | [Performance, correctness, security](05-operations/01-performance-correctness-security.md) | developers, auditors | 25 min |
+| 15 | [Debugging and maintenance workflows](05-operations/02-debugging-and-maintenance-workflows.md) | developers, maintainers | 25 min |
+| 16 | [Hardware and software matrix](06-portability/hardware-software-matrix.md) | developers, integrators | 20 min |
+| 17 | [Developer onboarding and standards](07-developers/onboarding-and-standards.md) | contributors | 20 min |
+| 18 | [HAAEEP and collaboration](08-ecosystem/haaeep-and-collaboration.md) | stakeholders, partners | 20 min |
+| 19 | [Glossary and FAQ](09-reference/glossary-and-faq.md) | everyone | reference |
 
 Deep-dive material lives in [`../wiki/`](../wiki/README.md) (firmware
 decompilation record, address reference, historical protocol notes). Wiki