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, 16 insertions, 11 deletions

diff --git a/docs/03-architecture/01-system-overview.md b/docs/03-architecture/01-system-overview.md
index c7a847e..5c2ba6c 100644
--- a/docs/03-architecture/01-system-overview.md
+++ b/docs/03-architecture/01-system-overview.md
@@ -61,10 +61,12 @@ HOST MODULE  open-iov-vfio.ko
   ├─ emulation core: GSP boot + GSP-RM (RPC msgq, controls, objects, events)
   ├─ memory model: guest RAM access, VA↔PA maps, VRAM backing
   └─ work path: channel/push forwarding to the physical GPU   [goal; software bridge today]
-        │
-HOST DRIVER  nvidia.ko (unmodified) and/or direct GPU interfaces
-        │
-PHYSICAL GPU
+        │ module-owned device + real GSP session
+HOST BACKEND  the GPU's own hardware + GSP firmware, driven by this module
+        │     (the distribution nvidia.ko stays unmodified and unbound in
+        │      this mode; see 08-physical-gpu-integration.md)
+        v
+REAL HARDWARE (engines, memory, interrupts)
 ```
 
 ## 3. Host module architecture
@@ -167,11 +169,12 @@ decompiled and mapped (see `wiki/GSP-570.144W-Firmware-Analysis.md` and
    `SUCCESS` with zeroed params, and `GSP_RM_ALLOC` echoes the request params
    without server-side object management. Where the driver consumes a reply
    value, that value is still being corrected (the reply-fidelity ladder).
-5. `nvidia-smi` works; CUDA user-space starts (`cuInit` / `cuDeviceGet`
-   succeed). Context creation is currently blocked: `cuCtxCreate` returns
-   `rc=999` (`CUDA_ERROR_UNKNOWN`) because the emulated engine list lacks the
-   async copy engine (`COPY14`), so UVM's channel-manager and page-tree
-   initialization is as far as the guest gets.
+5. `nvidia-smi -L` enumerates the emulated device and CUDA user-space starts
+   (`cuInit` / `cuDeviceGetCount` / `cuDeviceGet` succeed). The client reaches
+   `cuCtxCreate`, which currently ends in a forced `rc=999` on a completion
+   wait; the copy-engine method streams execute in software as a bridge, and
+   the execution backend is not built yet (see
+   [`08-physical-gpu-integration.md`](08-physical-gpu-integration.md)).
 
 The CUDA-side contract and the reply-fidelity rules are documented in
 [`../../userspace/cuda/docs/03-driver-and-gpu-interface.md` §9](../../userspace/cuda/docs/03-driver-and-gpu-interface.md)
@@ -192,7 +195,9 @@ That means the host module must:
    faults and semaphores back.
 
 The design for this, including what is known and what remains to be learned, is
-in:
+in
 [`../04-implementation/01-known-knowns-and-unknowns.md`](../04-implementation/01-known-knowns-and-unknowns.md)
 and
-[`../04-implementation/02-practical-challenges-and-adversarial-interop.md`](../04-implementation/02-practical-challenges-and-adversarial-interop.md).
+[`../04-implementation/02-practical-challenges-and-adversarial-interop.md`](../04-implementation/02-practical-challenges-and-adversarial-interop.md);
+the chosen execution backend is specified in
+[`08-physical-gpu-integration.md`](08-physical-gpu-integration.md).