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, 10 insertions, 9 deletions

diff --git a/docs/09-reference/glossary-and-faq.md b/docs/09-reference/glossary-and-faq.md
index 2ec4faa..e0c68f6 100644
--- a/docs/09-reference/glossary-and-faq.md
+++ b/docs/09-reference/glossary-and-faq.md
@@ -5,7 +5,7 @@
 | Term | Meaning |
 |---|---|
 | **AMAPlib** | NVIDIA's shared "address mapping" library: swizzling, bank/channel mapping, aperture rules. Studied for page-table and memory-layout semantics. |
-| **Async copy engine (COPY14)** | A copy-engine instance found in the host oracle's engine list but missing from the emulated list — engine descriptor `0x793ceb0e`, instance 14, client type `0x38`, class pair `0xc9b5`. Its absence is the current CUDA context-creation blocker. |
+| **Async copy engine (COPY14)** | A copy-engine instance found in the host oracle's engine list; engine descriptor `0x793ceb0e`, instance 14, client type `0x38`, class pair `0xc9b5`. Its earlier absence from the emulated list was a context-creation blocker; the emulated inventory now includes it (two GRCEs). |
 | **BAR0 / BAR1 / BAR3** | PCI BAR windows of the GPU: register interface (16 MB), VRAM aperture (256 MB), instance/PRAMIN window. |
 | **CE** | Copy Engine: DMA engine; also used for UVM's internal work. |
 | **Class list (classDB)** | The set of RM classes reported as supported (`GPU_GET_CLASSLIST`); engine queries are filtered against it, so the class list, engine list and caps controls must agree. |
@@ -63,14 +63,15 @@ Yes — in the standalone configuration the distribution driver owns the physica
 GPU and Open-IOV is an independent module. Building NVIDIA's OpenRM modules from
 source is only needed for the native-vGPU-management workflows.
 
-**Why is `nvidia-smi` working but CUDA not?**
-CUDA startup reaches `cuInit` / `cuDeviceGet`, but context creation is blocked:
-the emulated engine list lacks the async copy engine (`COPY14`), so
-`cuCtxCreate` returns `rc=999` (`CUDA_ERROR_UNKNOWN`) and memory allocation
-never runs. (The earlier `libcuda` segfault on this path was fixed by echoing
-the request params back in the alloc reply.) Once context creation is green,
-CUDA still needs *execution*: kernels must run on real hardware. See the
-known-knowns document for the exact status and plan; start at
+**Why is `nvidia-smi` working but my CUDA kernel not running?**
+The driver-API path works: `cuInit`, device enumeration, `cuCtxCreate` and
+the full smoke test (allocation, copies, free and destroy) complete, and a
+guest kernel launch is forwarded to the physical engine queue. What has not
+been observed yet is *execution*: the engine does not execute the forwarded
+launch descriptor and no engine-authored release appears. That is the current
+frontier, not a setup problem; the chosen execution backend is documented in
+[`../03-architecture/08-physical-gpu-integration.md`](../03-architecture/08-physical-gpu-integration.md).
+See the known-knowns document for the exact status and plan; start at
 [`../../userspace/cuda/READ-ME-FIRST.md`](../../userspace/cuda/READ-ME-FIRST.md).
 
 **How is this legal / license-clean?**