docs: Stage 0 --- retract a "verified", fix the contract, split route from binding

Three findings, one of which is a retraction.

GPU 3(c) is inferred again, in BOTH halves. The previous commit called
its rendering half "verified" on gpu_invocation_acceptance.rs:706. That
test runs `--headless-managed-probe`, which connects, receives and
DECODES a `BufferSnapshot` into text; it never constructs GPU render
state and never calls `render_offscreen` (pmacs-gpu/src/main.rs:1065).
It witnesses delivery and decoding, which is real and is not rendering.
Retracted rather than softened: "verified" was the word doing the
damage, and this file is where a reader goes to find out what has
actually been measured.

The discoverability contract said the four welcome key entries decide
every discoverability grade --- while the table two paragraphs below it
graded steps 4 and 7 on welcome PROSE and on the help graph. A standard
cannot carry both. The contract now states what it actually applies:
advertisement includes the welcome's prose (`M-x`, `M-x help` at
welcome.lua:61) and is TRANSITIVE through the help graph, which is how
`help.list-keybindings` carries browse and symbol.

That transitivity forced the distinction 11(c) was already resting on
without saying so: a BINDING is a stronger claim than a ROUTE. Step 7
passes because its commands are bound and a listing names them; step 11
fails because `*workers*` has no binding for any listing to name. So the
summary's "no advertised route at all" was FALSE --- the route is
`M-x help` -> `help.list-commands` -> `editor.list-workers` --- and the
Missing grade survives on the binding, exactly as 11(c) is worded.

The framing's worked examples are marked HISTORICAL, with COHERENCE.md
§2b named authoritative. A framing and the standard it serves were
handing a reader two different grades for step 7. Both examples keep
their point: the head-grade rule would have graded BOTH `Works`, which
is what makes it unsound. Step 7 moving on better evidence is the system
working; step 11 not moving is the defect surviving contact with it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai

COHERENCE.md

@@ -437,9 +437,23 @@ frontend-local one.
 
 Anchors: `COHERENCE.md` §2's ground-truth rows, the GUI arc audit at
 `4bc55e8` (`docs/gui-arc-framing.md` §2), Q#DS9
-(`docs/desktop-save-framing.md`), and `builtin/runtime/welcome.lua`,
-whose advertised set is exactly `C-x C-f`, `C-c t`, `C-c c`, `C-x b` —
-which is what decides every discoverability subclaim below.
+(`docs/desktop-save-framing.md`), and `builtin/runtime/welcome.lua`.
+
+**What counts as "advertised in-product", stated because an earlier
+draft of this paragraph got it wrong and mis-graded two steps.** The
+welcome advertises **both** a key table (`C-x C-f`, `C-c t`, `C-c c`,
+`C-x b`) **and prose** — its first line names `M-x` and `M-x help`
+(`welcome.lua:61`). Advertisement is therefore **transitive through the
+help graph**: a command reachable from an advertised route counts as
+advertised, which is how `help.list-keybindings` carries browse and
+symbol (step 7) and how `help.list-commands` carries
+`editor.list-workers` (step 11). Reading only the four-entry key table
+is what produced the earlier `Partial` at steps 4 and 7.
+
+**A binding is a stronger claim than a route, and 11(c) asks for the
+binding.** That is why step 11 still fails while step 7 passes: both are
+reachable through the help graph, but `*workers*` has **no binding for
+any listing to name**.
 
 | # | Step | local TUI | attached TUI | GPU | binding subclaim |
 |---|---|---|---|---|---|
@@ -467,7 +481,9 @@ is a property of the tree rather than of the grader.
 **The journey's two worst steps are frontend-INDEPENDENT**, and that is
 the table's other finding. Steps 6 and 11 grade `Missing` in all three
 columns: language intelligence dies silently after a server crash, and
-background work has no advertised route at all. Neither is GUI work,
+background work has no advertised **binding** — a route exists
+(`M-x help` → `help.list-commands` → `editor.list-workers`), which is
+why 11(c)'s wording asks for a binding and not a route. Neither is GUI work,
 neither is closed by this arc, and both were previously carried as
 `Partial` — which is how they stayed off the critical path.
 
@@ -479,14 +495,20 @@ fails on GPU *alone*, so it is **frontend-local** — Stage 1d's IME work
 closes it. A single merged TUI column would have shown two identical
 red cells and no way to tell those apart.
 
-**Inference flags, narrowed to what is actually unverified.** GPU
-3(c)'s *rendering* half is **verified**, not inferred:
-`gpu_invocation_acceptance.rs:706` drives a GPU directory target and
-asserts the dired listing reaches and renders on that frontend. What
-remains inferred is **browsing interaction** there, plus GPU 9 (that
-compile output renders like any other daemon buffer) and GPU 6(c) (that
-hover reaches the echo area as it does on the grid). Those three must be
-verified before this table is used as a release gate.
+**Inference flags.** GPU 3(c) is inferred **in both halves** —
+rendering and browsing interaction — as are GPU 9 (compile output
+renders like any other daemon buffer) and GPU 6(c) (hover reaches the
+echo area as on the grid). All must be verified before this table is
+used as a release gate.
+
+*An earlier draft called 3(c)'s rendering half "verified" on
+`gpu_invocation_acceptance.rs:706`. That test runs
+`--headless-managed-probe`, which connects, receives and DECODES a
+`BufferSnapshot` into text; it never constructs GPU render state and
+never calls `render_offscreen` (`pmacs-gpu/src/main.rs:1065`). It
+witnesses delivery and decoding — which is real, and is not rendering.
+Retracted rather than softened, because "verified" was the word doing
+the damage.*
 
 ### Ground truth: the journey today
 

docs/gui-arc-framing.md

@@ -413,14 +413,27 @@ step in the table declares its required subclaims explicitly; the cell's
 grade is the **minimum** over them, never the first word of a prose
 verdict.
 
-The worked examples are not hypothetical — they are the two rows
-`COHERENCE.md` §2 carries today:
+**The worked examples below are HISTORICAL, and `COHERENCE.md` §2b is
+authoritative for every current grade.** They are kept because they are
+what motivated this rule, and they are marked because a framing and the
+standard it serves must not hand a reader two different grades for one
+step. They quote the **pre-Stage-0** verdict strings, not today's table:
 
-- **Step 7** — "Symbol: **works but undiscoverable**". Subclaims
-  *reachable* / *discoverable*: `Works` and `Missing`. Cell grade
-  **`Missing`**.
-- **Step 11** — "**Works but undiscoverable**". Same shape, same
-  result.
+- **Step 7** — the row then read "Symbol: **works but
+  undiscoverable**". Subclaims *reachable* / *discoverable*: `Works` and
+  `Missing` ⇒ **`Missing`**. **Stage 0 graded it `Works`** on evidence
+  this example did not have: advertisement is transitive through the
+  help graph, and the advertised `M-x help` route reaches
+  `help.list-keybindings`, which names every registered binding.
+- **Step 11** — the row then read "**Works but undiscoverable**". Same
+  shape, and here the outcome **stands**: Stage 0 also graded it
+  `Missing`, because `*workers*` has no binding for any listing to name.
+
+The rule these examples exist to establish is untouched by either
+outcome: **the head-grade rule would have graded both `Works`**, and
+that is what makes it unsound. Step 7 moving on better evidence is the
+system working; step 11 not moving is the defect surviving contact with
+it.
 
 Under revision 2's head-grade rule **both would have graded `Works`**,
 and the undiscoverability that is the entire finding would have become