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, 20 insertions, 15 deletions

diff --git a/docs/04-implementation/02-practical-challenges-and-adversarial-interop.md b/docs/04-implementation/02-practical-challenges-and-adversarial-interop.md
index e2769f8..3265f47 100644
--- a/docs/04-implementation/02-practical-challenges-and-adversarial-interop.md
+++ b/docs/04-implementation/02-practical-challenges-and-adversarial-interop.md
@@ -57,28 +57,33 @@ without a methodology is not accepted in this project.
   memsets, copies and semaphore releases — is executed in software as a
   correctness bridge; no CUDA kernel is forwarded yet.
 
-## 3. Forwarding: the three options and how we choose
+## 3. Forwarding: the options and the chosen mechanism
 
 ```
-   (A) Host RM/GSP proxy
-       guest push → translate → host driver's RM API → real channel → GPU
-       + reuses a mature driver's knowledge
-       − extra hop, depends on host driver interfaces
+   (A) Proxy through the host driver
+       guest push → translate → host driver's RM → real channel → GPU
+       Not implementable with an unmodified distribution driver: no callable
+       RM entry point from kernel context (see 03-architecture/08).
 
-   (B) Direct engine submission
-       guest push → translate → our own channel/push construction → GPU
-       + lowest latency, no host driver dependency
-       − we must own page tables, scheduling, invalidation, completion
+   (B) Own the GPU; own scheduling (no GSP)
+       guest push → translate → our own channels/runlists/page tables → GPU
+       Reproduces the scheduler and MMU ownership; large, capability-limiting.
 
    (C) Hybrid
-       management via (A), hot path via (B)
+       Only meaningful once (A) and (B) both exist.
+
+   (D) Own the GPU; use its real GSP firmware as the server   ← chosen
+       guest push → translate → real GSP-RM session → real channel → GPU
+       The module is the host-side resource-manager client; the firmware
+       schedules.
 ```
 
-**Decision procedure:** prototype (A) first to get *correct* execution, with
-measurement harnesses around it. Then measure the overhead. If the overhead
-violates the budgets in §2.2 for the target workloads, implement (B) for the
-hot path and keep (A) for management. The architecture must not preclude
-either, so the work path is abstracted behind an interface from day one.
+The full analysis — which interfaces exist, why the proxy is unavailable, and
+the ownership model — is in
+[`../03-architecture/08-physical-gpu-integration.md`](../03-architecture/08-physical-gpu-integration.md).
+The work path stays abstracted behind one interface so the backend can be
+swapped. Software execution of decoded state/memory operations remains a
+correctness bridge for bring-up, not the data plane.
 
 ## 4. Hard problems we must solve, and our stance on each