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

diff --git a/docs/03-architecture/04-uvm.md b/docs/03-architecture/04-uvm.md
index b879572..4c8a0c9 100644
--- a/docs/03-architecture/04-uvm.md
+++ b/docs/03-architecture/04-uvm.md
@@ -50,17 +50,20 @@ Each stage has a distinct failure signature; our debugging docs map them.
 | Requirement | Detail | Our status |
 |---|---|---|
 | GPU identity | must match the uuid from RM | ✅ |
-| CE capabilities | per-engine support bits; UVM *requires* `supported && !grce && sysmem` for CPU_TO_GPU/GPU_TO_CPU channels | 🟡 the caps we answer are accepted, but the engine list / CE capabilities are missing the async copy engine (`COPY14`) — the current context-creation blocker |
+| CE capabilities | per-engine support bits; UVM *requires* `supported && !grce && sysmem` for CPU_TO_GPU/GPU_TO_CPU channels | 🟡 the caps we answer are accepted and the inventory now includes the async copy engine; completion/semaphore plumbing is the current frontier |
 | Channel creation | RM channel objects with GPFIFO/userd/instance parameters | ✅ objects created |
 | Pushes executed | UVM's first action on a new channel is an *init push* followed by a semaphore-tracked wait | 🟡 the host decodes method streams and executes memsets, copies and semaphore releases in software (a bridge); no kernel is forwarded to the physical GPU yet |
 | Page trees | UVM initializes page trees with its own pushes; the *server-owned* ranges must be populated by us | 🟡 |
 | Fault delivery | fault buffer + notification; replay/cancel semantics | 🔴 |
 | Semantics of completions | tracker values must advance exactly | 🟡 |
 
-**Current blocker (2026-09-23):** `cuCtxCreate` returns `rc=999`
-(`CUDA_ERROR_UNKNOWN`) because the emulated engine list lacks the async copy
-engine (`COPY14`); teardown of the failed context still oopses in the guest
-kernel in `uvm_pmm_devmem_page_to_va_space` (twice per boot). The CUDA-side
+**Current frontier (2026-09-29):** the client reaches `cuCtxCreate` and
+currently ends in a forced `rc=999` on a completion wait; the engine inventory
+is complete, and the remaining work is completion translation plus the chosen
+execution backend
+([`08-physical-gpu-integration.md`](08-physical-gpu-integration.md)).
+Failed-context teardown has produced guest kernel oopses in
+`uvm_pmm_devmem_page_to_va_space` in earlier runs. The CUDA-side
 contract and reply rules are in
 [`../../userspace/cuda/docs/03-driver-and-gpu-interface.md` §9](../../userspace/cuda/docs/03-driver-and-gpu-interface.md)
 and