wiki: refresh the status pages for the 2026-11-09 campaign

Bring Project-Status, OpenGL, Graphics-Execution, Execution-Frontier,
Execution-Plane, Physical-GPU-Backend, Host-Module, System-Overview,
Project-Goals, Project-Plan and the FAQ in line with the current state:
display/KMS on the emulated vGPU is live, glxinfo reports OpenGL 4.6.0
with direct rendering, and the remaining graphics gate is the X GLX
context-creation completion plus the client kick-slot word.

1 files changed, 7 insertions, 5 deletions

diff --git a/wiki/Physical-GPU-Backend.md b/wiki/Physical-GPU-Backend.md
index 976430d..8f1a02b 100644
--- a/wiki/Physical-GPU-Backend.md
+++ b/wiki/Physical-GPU-Backend.md
@@ -5,7 +5,7 @@
 > guest-facing emulation. Canonical sources: [`../docs/03-architecture/08-physical-gpu-integration.md`](../docs/03-architecture/08-physical-gpu-integration.md)
 > and [`../docs/03-architecture/11-physical-backend-guest-wiring.md`](../docs/03-architecture/11-physical-backend-guest-wiring.md); the docs tree wins on disagreement.
 
-Status: 2026-10-30, tree `master @ b4930168`. Tags: `[live]` proven with the
+Status: 2026-11-09, tree `master @ 4acc81e8`. Tags: `[live]` proven with the
 stock guest driver; `[gated]` implemented default-off; `[wip]` partially
 built; `[wall]` current blocker; `[target]` planned end state.
 
@@ -109,7 +109,7 @@ FAIL  a failed mutating operation parks the device in a locked fail-safe;
 | Host RM client and first real engine work (static config, real objects, 4 KiB CE copy) | done `[live]` |
 | Guest-copy forwarding, deferred release, hardware-primary copies, engine-authored relay, fault relay | verified live (seams parameterised and fail-open); the staged-transfer class is under repair `[live]` |
 | CUDA kernel execution (`vectorAdd` and further clients) | done `[live]` — stock guest CUDA clients (vector-add, matrix-multiply, transformer) execute on the physical engine with verified results and engine-authored completions relayed to the guest |
-| Graphics method-stream execution (verbatim 3D replay, synthesized launches) | `[wip]` — the engine retires real graphics streams and launched kernels; rendered pixels are the frontier ([`Graphics-Execution.md`](Graphics-Execution.md)) |
+| Graphics method-stream execution (verbatim 3D replay, synthesized launches, direct-GL client channels) | `[wip]` — the engine retires real graphics streams, the display/KMS stack registers and the direct GL client's GR/CE channels submit; rendered pixels are the frontier ([`Graphics-Execution.md`](Graphics-Execution.md)) |
 
 ## 7. The execution frontier
 
@@ -119,9 +119,11 @@ engine: the inline launch descriptor installs and is read, the grid
 dispatches, the engine authors the completion, the host relays it, and the
 guest's synchronisation wait resolves — verified on fresh boots with the
 vector-add, matrix-multiply and transformer clients. Graphics work rides the
-same machinery in two lanes (a verbatim 3D method-stream replay and
-synthesized launches) and executes on the engine; producing rendered pixels
-is the graphics frontier. The remaining compute work is the staged-transfer
+same machinery in three shapes (a verbatim 3D method-stream replay,
+synthesized launches, and the direct GL client's own GR/CE channels) and
+executes on the engine; the display/KMS stack registers and X settles, so the
+remaining graphics gate is the X GLX context-creation completion before
+rendered pixels. The remaining compute work is the staged-transfer
 class (under repair), the every-boot acceptance campaign, and per-guest
 execution isolation — see
 [`Execution-Frontier.md`](Execution-Frontier.md) and