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

diff --git a/docs/03-architecture/05-gmmu-amap-hal-gr.md b/docs/03-architecture/05-gmmu-amap-hal-gr.md
index 6111f54..76d4200 100644
--- a/docs/03-architecture/05-gmmu-amap-hal-gr.md
+++ b/docs/03-architecture/05-gmmu-amap-hal-gr.md
@@ -186,10 +186,11 @@ engine type (e.g. `COPY0 = 0x9`, `GR = 0x1`).
 driver builds its per-engine records from the device/engine information the
 kernel driver reports, and filters them against the class list; a missing or
 zeroed record is not ignored - it becomes an allocation with class `0` and the
-whole context setup rolls back. The current CUDA bring-up blocker is exactly
-this: the async copy engine (COPY14, engine descriptor `0x793ceb0e`, instance
-14) is absent from the emulated engine list, while a bare-metal oracle reports
-it as the seventh engine alongside GR and CE0..4. See
+whole context setup rolls back. This was exactly the CUDA bring-up blocker
+until the engine inventory was completed: the async copy engine (COPY14,
+engine descriptor `0x793ceb0e`, instance 14) was absent from the emulated
+engine list, while a bare-metal oracle reports it as the seventh engine
+alongside GR and CE0..4; it is now included. See
 [`../../userspace/cuda/docs/05-570.144-decompilation.md`](../../userspace/cuda/docs/05-570.144-decompilation.md)
 section 3.7 for the record layout the driver's engine walker consumes.