docs: add the GR compute-launch frontier page and align execution status across the tree

New page docs/04-implementation/03-execution-frontier.md describes the chain
that must fire for a guest CUDA launch (guest push -> GPFIFO/front-end ->
inline launch-descriptor install -> engine read/dispatch -> completion),
where the leading edge is (the descriptor install path), how we know
(front-end vs engine-authored observables and their limits), what is
exonerated (context validity at dispatch, destination window mapping,
fetch alignment, shared-buffer rule, parenting), the ranked issues (verbatim
prelude targets, missing descriptor-virtualization control, sentinel
hygiene), live investigation lines and labelled theories.

Align every page that still said GR execution is blocked on engine-context
validity to the current frontier, and add the new page to the README reading
order (row 15, later rows renumbered). Docs only; no code.

1 files changed, 14 insertions, 7 deletions

diff --git a/docs/04-implementation/01-known-knowns-and-unknowns.md b/docs/04-implementation/01-known-knowns-and-unknowns.md
index 084afc8..881d608 100644
--- a/docs/04-implementation/01-known-knowns-and-unknowns.md
+++ b/docs/04-implementation/01-known-knowns-and-unknowns.md
@@ -28,8 +28,10 @@ listed as an unknown-unknown has a *method* by which we will discover it.
   copies are verified byte-for-byte. The execution backend is live: CE-class copies are
   forwarded to the physical copy engine (default off) with engine-authored
   semaphore releases and a fault relay; the remaining frontier is engine
-  execution — GR kernel execution is blocked on GR engine-context validity
-  (see §2.1).
+  execution — a forwarded guest launch now reaches the front-end (entry
+  fetched, methods run) but the inline launch-descriptor install has not been
+  observed and no grid has dispatched; context validity at dispatch is ruled
+  out (see §2.1 and [`03-execution-frontier.md`](03-execution-frontier.md)).
 * The same guest **boots unmodified**: no guest code, no guest module
   parameters are required for the initialization path.
 * The host is unmodified in the standalone configuration (distribution NVIDIA
@@ -111,15 +113,20 @@ the physical GPU and run its real GSP firmware as the resource-manager server
 (the module becomes the host-side RM client). That backend is now live: CE-class
 copies and their releases are forwarded to the physical copy engine (default
 off) with a fault relay, while the emulation path remains the control plane.
-What is still open is **GR (kernel) execution**, blocked on GR engine-context
-validity.
+What is still open is **GR (kernel) execution**: a forwarded guest launch now
+reaches the front-end (ring entry fetched, methods run) but the inline
+launch-descriptor install has not been observed and no grid has dispatched —
+context validity at dispatch is ruled out. The chain, evidence and live
+investigation lines are in
+[`03-execution-frontier.md`](03-execution-frontier.md).
 
 **Why:** GR execution is *the* blocker for CUDA kernels, and later for
 graphics.
 
-**Plan:** finish the backend in stages: GR engine-context validity and kernel
-submission; translation of the remaining guest work; completion and fault relay
-for every engine class. Measure each stage against a scorecard: correctness,
+**Plan:** finish the backend in stages: the launch-descriptor install path and
+GR kernel submission (see
+[`03-execution-frontier.md`](03-execution-frontier.md)); translation of the
+remaining guest work; completion and fault relay for every engine class. Measure each stage against a scorecard: correctness,
 isolation, latency, maintenance cost across driver versions. Deliverable: a
 forwarded `vectorAdd` with verified results. Alternatives (own scheduling
 without GSP; vendor vGPU or SR-IOV paths) are analyzed and rejected or