kernel: GR context-promote bisection modes 4-17 and server-managed-ctxbuf registry variant; complete vgsp rename; docs/tooling refresh

- gsp_phys_booter: GR promote bisection modes 4-17 (two-phase zero-field VA,
  batched entries, hVirtMemory, bare VA, KMD SKIP_CTXBUFFER_ALLOC channel,
  old-interface GPU_INITIALIZE_CTX, FBMEM context buffer, UVM-faithful PA-only,
  PATCH/PM auxiliary promotes, server-managed no-promote path); PATCH/PM
  geometry queries and buffers; pre-boot SET_REGISTRY profile selection
- gsp_phys_gpu: gsp_phys_rmcall_gr_promote clamp 0..17 and gsp_phys_srv_ctxbuf
  parameter; registry image variant with RMSetClientRMAllocatedCtxBuffer=0
- vgsp rename across kernel, scripts, tools and docs (module vgsp.ko,
  /sys/kernel/debug/vgsp/, vgsp-<subsystem>: log prefixes)
- risc-v-gsp-rm-debugger user-facing rename and docs/CI refresh; guest-diag
  tool updates; README/SBOM/install/Makefile sync

Live status: CE ladder and P6 guest-copy forwarding green; GR engine context
commit still open (all promote shapes accepted or cleanly refused; the channel
stays CTXNOTVALID) - see Handoff-vGPU-IO.md Addendum 21 (local).

3 files changed, 3 insertions, 3 deletions

diff --git a/userspace/cuda/570.144/docs/ANALYSIS-cuctxcreate-segv.md b/userspace/cuda/570.144/docs/ANALYSIS-cuctxcreate-segv.md
index 666a4e2..ce9872d 100644
--- a/userspace/cuda/570.144/docs/ANALYSIS-cuctxcreate-segv.md
+++ b/userspace/cuda/570.144/docs/ANALYSIS-cuctxcreate-segv.md
@@ -27,7 +27,7 @@ First analysis note for the CUDA userspace driver under Open-IOV. Companion to
 | `cuMemAlloc` / copies / `ALL OK` | not reached yet |
 
 Guest: Ubuntu 24.04, driver **570.144** (open kernel modules + libcuda
-570.144), emulated TU104 `10de:1ed3` via `open-iov-vfio.ko`.
+570.144), emulated TU104 `10de:1ed3` via `vgsp.ko`.
 Host oracle: RTX 2080 Super (cc 7.5), driver 570.211.01, CUDA toolkit 12.0.
 
 ## The crash, precisely
diff --git a/userspace/cuda/docs/04-virtualization-and-emulation.md b/userspace/cuda/docs/04-virtualization-and-emulation.md
index 6492a60..cb77652 100644
--- a/userspace/cuda/docs/04-virtualization-and-emulation.md
+++ b/userspace/cuda/docs/04-virtualization-and-emulation.md
@@ -94,7 +94,7 @@ stock** — but implements the host side differently:
 | Guest stack | stock | stock (identical constraint) |
 | Device presented | mediated PCI function with a vGPU profile, backed by host RM | emulated PCI function (mdev/VFIO) backed by the host module + GSP-RM emulation |
 | Where commands execute | physical GPU via host RM channels | host executes the work the guest encodes (e.g. memsets/copies/semaphore releases) or passes through, depending on the resource |
-| Host-side control plane | vGPU manager daemon + VMIOP plugin + host RM | `open-iov-vfio.ko` emulating the GSP-RM interface and device model directly in the kernel |
+| Host-side control plane | vGPU manager daemon + VMIOP plugin + host RM | `vgsp.ko` emulating the GSP-RM interface and device model directly in the kernel |
 | Licensing | GRID license server / vGPU licensing; CUDA gated on license state | no GRID licensing; the driver's vGPU detection must be answered in a way that does not gate CUDA (or the guest must not be told it is a licensed-vGPU-only environment) |
 | CUDA userspace | unmodified, capability-limited by vGPU profile | unmodified, no profile limits imposed |
 | Migration | vGPU-specific save/restore protocol with dirty-page tracking | 4-phase migration in the host module (project feature) |
diff --git a/userspace/cuda/docs/08-virtualization-approaches.md b/userspace/cuda/docs/08-virtualization-approaches.md
index e67f648..6e9702d 100644
--- a/userspace/cuda/docs/08-virtualization-approaches.md
+++ b/userspace/cuda/docs/08-virtualization-approaches.md
@@ -46,7 +46,7 @@ server. Approach E remains deployment-gated.
 **Stated architecture:** *emulate the interface, pass through the work, never
 patch anyone* — a mediated-passthrough vGPU where PCI config/BARs, the GSP boot
 handshake, the GSP-RM protocol and interrupt routing are emulated in
-`open-iov-vfio.ko`, while real work is meant to execute on the physical GPU.
+`vgsp.ko`, while real work is meant to execute on the physical GPU.
 The original decision procedure was to prototype A first for correctness; the
 interface analysis
 ([`../../../docs/03-architecture/08-physical-gpu-integration.md`](../../../docs/03-architecture/08-physical-gpu-integration.md))