docs: record the first real GSP boot and the live GSP-RM session

STATE-CURRENT and the architecture docs now describe the observed order (FWSEC -> Booter Load -> RISC-V active -> event 0x1002 run-sequencer -> 0x1001 init-done), the four-handoff-bit clean-release constraint, and the --boot/--keep harness contract.

1 files changed, 10 insertions, 0 deletions

diff --git a/docs/03-architecture/03-gsp-and-gsp-rm.md b/docs/03-architecture/03-gsp-and-gsp-rm.md
index fe51838..7f206ba 100644
--- a/docs/03-architecture/03-gsp-and-gsp-rm.md
+++ b/docs/03-architecture/03-gsp-and-gsp-rm.md
@@ -54,6 +54,16 @@ Our emulation implements stage completion rather than the stages themselves —
 which is legitimate because the *only observable* to the driver is the state
 machine it polls.
 
+On the physical path (2026-10-01), the same handshake ran against real
+firmware: FWSEC raised WPR2 with a zero FRTS error code, the SEC2 booter halted
+with mailbox0 = 0, the RISC-V core reported active (`RISCV_STATUS=0x00000035`,
+active bit 0) and `FALCON_OS` read 0. The server's first message was then a
+status-queue event, function `0x1002` (`NV_VGPU_MSG_EVENT_GSP_RUN_CPU_SEQUENCER`,
+`rpc_result=0`), carrying a command buffer the host must execute;
+`GSP_INIT_DONE` (`0x1001`) follows only after that sequencer runs. The
+host-side queue pair behind the exchange is one shared page table plus a 256 KB
+command queue and a 256 KB status queue of 4 KB elements.
+
 ```mermaid
 sequenceDiagram
   autonumber