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, 16 insertions, 13 deletions

diff --git a/wiki/Execution-Frontier.md b/wiki/Execution-Frontier.md
index c8d42cc..e8efcc3 100644
--- a/wiki/Execution-Frontier.md
+++ b/wiki/Execution-Frontier.md
@@ -14,7 +14,7 @@
 > [`../docs/04-implementation/03-execution-frontier.md`](../docs/04-implementation/03-execution-frontier.md);
 > the docs tree wins on disagreement.
 
-Status: 2026-10-30, tree `master @ b4930168`.
+Status: 2026-11-09, tree `master @ 4acc81e8`.
 Tags: `[live]` observed; `[wip]` partial; `[wall]` current blocker; theories
 are labelled as such.
 
@@ -95,14 +95,16 @@ breadth and hardening around it:
 ### A parallel frontier: 3D graphics
 
 Graphics execution shares this page's submission and completion machinery but
-runs a different engine workload. The story so far: the X server and GLX run
-on the emulated vGPU; the emulation captures the X server's graphics-class
-stream and the engine executes it — both as a verbatim 3D method-stream replay
-and as a synthesized launch that retires real `sm_75` SASS — and the guest
-Vulkan pipeline runs end to end (device → command buffer → fence → readback).
-What is missing is **rendered pixels**: every frame is still black, and the
-program-delivery/program-VA-mapping pair is the working frontier. The full
-picture lives on [`Graphics-Execution.md`](Graphics-Execution.md).
+runs a different engine workload. The display and GL stacks now run end to
+end in the guest: the emulated display engine serves the modeset push buffers,
+nvidia-modeset/NvKms registers (`/dev/dri`), X settles, `glxinfo` reports
+OpenGL 4.6.0 with direct rendering, and GZDoom obtains a real GL context; the
+direct GL client's GR and CE channels submit and retire, and the X server's
+DDX kick channel is decoded. What is missing is **rendered pixels**: the
+remaining wall is the X GLX context-creation completion (with the client's
+kick-slot word), and every frame is still black. The guest Vulkan pipeline
+runs end to end but its inline-to-memory upload arm remains the named gap.
+The full picture lives on [`Graphics-Execution.md`](Graphics-Execution.md).
 
 No breadth beyond these is claimed: Windows guests, migration and performance
 numbers remain planned.
@@ -158,10 +160,11 @@ different emulated VRAM sizes and multiple guests coexist at the device level
 (two guests demonstrated); per-guest execution isolation for simultaneous
 CUDA guests is in progress.
 
-**Issue D — the graphics pixel frontier.** The engine executes graphics method
-streams, but no rendered (non-black) frame has been produced yet; program
-delivery and program-VA mapping are the named blockers
-([`Graphics-Execution.md`](Graphics-Execution.md)).
+**Issue D — the graphics pixel frontier.** The display/KMS stack and the GL
+client now run end to end (NvKms registers, X settles, GL 4.6, direct-GL
+channels submit and retire), but no rendered (non-black) frame has been
+produced yet; the X GLX context-creation completion and the client kick-slot
+word are the named blockers ([`Graphics-Execution.md`](Graphics-Execution.md)).
 
 ## 6. Lines of investigation (live)