docs: record GR promote-wall static findings (handler/commit map, external-VAS vaList gate, rec-677)

1 files changed, 12 insertions, 2 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 93ae38f..38017d5 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -65,8 +65,18 @@ isolation, performance, portability).
    compute-object alloc) wedges the server; three further cycles closed the
    client-promote shape space on the default external VAS with a soft
    `NV_ERR_INVALID_STATE` (0x40) each. The V5 commit assert `0x52a8b04` is a
-   secondary failure. Next routes: name the soft-0x40 check, root-cause the
-   V5 first failure, or rehost the promote flow in risc-v-gsp-rm-debugger.
+   secondary failure. Offline (2026-10-05): the promote control handler and its
+   commit chain are decompiled; the external-VAS branch is confirmed in
+   `kchannelMapEngineCtxBuf_IMPL` (a externally-owned VAS requires the engine
+   context VA to be booked in the server's `vaList`, which a raw-PTE client map
+   never creates, while a non-external VAS is mapped and booked by the server);
+   the V6 soft-0x40 is the known rec-677 message emitted through the promote
+   error machinery. The rec-677 format text lives in runtime-inflated metadata
+   (not in the shipped image), so naming it needs a live-GSP metadata dump.
+   Next routes: name the soft-0x40 record from live metadata, root-cause the V5
+   first failure (the log call site before the assert is now identified), or
+   root-cause the shared-management `TURING_COMPUTE_A` wedge; physical cycles
+   only with a named hypothesis and supervision.
 2. **Hardening the accepted no-claim path.** The first green guest CUDA
    acceptance has landed and is holding across repeats; what remains is the
    intermittent guest-side corruption flake (intermittent guest boot