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, 3 insertions, 3 deletions

diff --git a/docs/06-portability/hardware-software-matrix.md b/docs/06-portability/hardware-software-matrix.md
index 49c4bbe..c839578 100644
--- a/docs/06-portability/hardware-software-matrix.md
+++ b/docs/06-portability/hardware-software-matrix.md
@@ -131,9 +131,9 @@ the profile files, not the profile schema.
 ### 6.2 Engine-list portability
 
 The engine inventory, and how it is filtered by the class list (classDB), are
-per-architecture and per-driver data. Today's gap is concrete: the emulated
-list lacks the async copy engine (`COPY14`), which blocks context creation
-(`cuCtxCreate` returns `rc=999`). Engine inventory belongs in the hardware
+per-architecture and per-driver data. An earlier gap was concrete — a missing
+async copy engine (`COPY14`) blocked context creation until the inventory was
+completed — and it showed why the inventory belongs in the hardware
 profile, validated against the host oracle per combination. For the
 re-analysis workflow see
 [`../../userspace/cuda/docs/07-version-upgrade-playbook.md`](../../userspace/cuda/docs/07-version-upgrade-playbook.md);