docs: the tutor taught three keystrokes wrong, and the rest had drifted

The documentation had gone stale in the ordinary way -- claims that were true
when they were written and that nothing since had been obliged to re-read.
Some of them were load-bearing.

THE TUTOR. It still said there is no multi-cursor, that NextColor cycles three
themes, and that its practice blocks "are also run as unit tests (generated
from this file by tutor_gen)" -- a tool that appears nowhere in the tree, and
nothing anywhere parses a `# keys:` block. Left alone, that claim is what
makes the next wrong block survive.

Three of those blocks WERE wrong, and all three for one reason: since the
helix motion model landed, w/e/f/t SELECT the range they cross, so `i` after
one inserts at the SELECTION'S START. `w i Z esc` on "foo bar" gives
"Zfoo bar", not the "foo Zbar" the file promised. They were written against a
vim reading of the same keys. Every block in the file has now been run through
`zig build hxdiff` against the real core and matches byte for byte, and the
trap itself is written down in 3.3 rather than left to be rediscovered.

The tutor gains a PART 4 for everything added since it was written -- PDF
panes, the in-process ZLS backend, themes and fonts, the startup file -- and
PART 3 gains counts (and which keys ignore one), f/F/t/T, the whole g table
(bare `G` is a no-op; `ge` is the START of the last line), multiple cursors
and the s/S regex pair, `m`, `]`/`[`, `|`, insert mode, and all fifty leader
paths.

THE REST. design.typ's line table claimed 7,626 lines against a real 38,048,
and its rows did not sum to its own total; its Event/Effect boundary contract
-- the part a shell author writes against -- named four variants that do not
exist and omitted fourteen that do. lsp.md's probe count. config.md's
theme-name rules, which as written could not reach a zed theme at all.
helix-keys.md's Skipped section, holding five families that have since landed.
macos.md's menu bar, undocumented, along with sixteen other claims. web.md on
what the browser build can actually do.

SOURCE COMMENTS that had rotted alongside them: `tag_normal` is a space, not
the `•` its own comment describes; Wrap is ON by default, not off; a FontSel
row is SELECTED by n and RUN by Tab, not run by n; the SPC paths in lsp.zig
lost their `l` group prefix when the language group moved; and the
differential suites are 481 and 561 cases, not 360 and 440.

TWO THINGS FOUND BY DOCUMENTING THEM, both left standing and written down
rather than papered over. Typing `[^\n]` at an s/S prompt panics: the live
preview compiles every prefix, and `[^\` indexes an empty slice in mvzr's
parseCharSet. Both the tutor and a waiver recommended that pattern as the
workaround for `.` matching a newline; they now say what it costs and what
would make it sayable. And `Exec` is a builtin, so an `Exec` line in the
startup config types that command into a shell before the first frame -- the
tutor said nothing in that file is ever sent to one.

Nine adversarial reviews over two rounds, each with the hxdiff harness to
execute what it doubted. The second round exists because the first round's
fixes needed checking too, and it caught three regressions of my own -- one of
them a probe count I had "corrected" away from the truth.

Verified: unit-test, snap 87/87, hxdiff 481/0, hxparity 561/0, mupdf-check.
docs/design.pdf regenerated. The tutor's first seventeen lines are byte-
identical, which is what tutor.golden pins.

1 files changed, 45 insertions, 5 deletions

diff --git a/docs/config.md b/docs/config.md
index 7b35586c..30962ddb 100644
--- a/docs/config.md
+++ b/docs/config.md
@@ -8,6 +8,14 @@ Native pardes builds read a per-user `pardes` file before the first frame:
 - Windows: `%LOCALAPPDATA%\pardes`, with `%USERPROFILE%\AppData\Local\pardes`
   as the fallback.
 
+On the two unixes `XDG_CONFIG_HOME` counts only when it is ABSOLUTE, as the
+XDG base-directory specification requires; an empty or relative value falls
+back to the home-directory form. Windows never consults it. A file of 1 MiB or
+more, or one that cannot be read, is treated as no file at all — the path
+still resolves, because "nothing is there yet" is the answer `Config` exists
+to give. There is one case with no path at all: a native launch with no `HOME`
+set, which `Config` reports as such.
+
 `Config` (`SPC f c`, or the word executed anywhere) prints the resolved path
 into a `+Config` output pane, so the machine answers this rather than the list
 above. The path is printed whether or not a file is there — that is the case
@@ -15,6 +23,8 @@ you ask in — and the row is ordinary text, so a right click on it opens the
 file.
 
 The browser build has no local user-config path and does not load this file.
+(Nor does it have the `Font` builtin, or a language backend, or ptys of its
+own — see `docs/web.md`.)
 
 The format is one existing builtin command per line, using the same spelling
 and argument parsing as commands executed inside pardes:
@@ -22,14 +32,44 @@ and argument parsing as commands executed inside pardes:
 ```text
 Theme acme
 Font DejaVuSansMono-Regular
+Shell zsh
+Wrap
 ```
 
-On the SDL GUI, a selected face falls back to embedded Adwaita Mono, then to
-installed `NotoSansMono-Regular`, `DejaVuSansMono`,
+A line matches a builtin whose name takes NO argument only as that whole word:
+`Kill` runs, `Kill something` does not. Builtins that take one (`Theme`,
+`Font`, `Shell`, `Restore`, `Find`, `Grep`, `Rename`, `WsSymbols`, `Look`,
+`Exec`) take everything after the name as the argument.
+
+`Theme <name>` wants one of the 228 names in the ring. Do not derive the
+spelling — read it off `ThemeSel` (`SPC t t`), which lists every one as the
+exact `Theme <name>` line that selects it. The generator lowercases, folds
+punctuation runs to a single `_` and then TRIMS leading and trailing ones
+(`penumbra+.toml` is `penumbra`, not `penumbra_`), and it suffixes every theme
+that came from zed with `_zed` so it cannot collide with a helix theme of the
+same name (zed's "Ayu Mirage" is `ayu_mirage_zed`; `ayu_mirage` is helix's).
+A name that is not in the ring is ignored.
+
+`Shell <name>` sets the binary that the NEXT terminal pane execs; panes
+already open keep the shell they are running. A bare name is resolved against
+the handful of directories a shell actually lives in, not `$PATH`.
+
+`Font` and `FontSel` exist ONLY in the SDL GUI and native macOS builds — a
+terminal's font belongs to its emulator and a browser's to the page — so a
+`Font` line is one of the silently-ignored ones everywhere else. Both builds
+resolve the name by walking the font directories on every lookup, so a face
+installed a moment ago is findable.
+
+What happens to a codepoint the chosen face has no glyph for differs by shell.
+The SDL GUI falls back through a chain it builds itself: embedded Adwaita
+Mono, then installed `NotoSansMono-Regular`, `DejaVuSansMono`,
 `SymbolsNerdFont-Regular`, `NotoSansSymbols2-Regular`,
-`NotoSansSymbols-Regular`, and `DejaVuSans`, in that order. Missing entries are
-skipped. Faces are discovered and opened once at startup, and each resolved
-glyph is retained in the GPU atlas cache.
+`NotoSansSymbols-Regular`, and `DejaVuSans`, in that order, missing entries
+skipped; the rasterized glyphs are retained in its GPU atlas. The macOS shell
+has none of that and needs none: it embeds no font, substitutes the system
+monospaced face (else Menlo) when the NAME you asked for will not load, and
+leaves per-codepoint fallback to CoreText's own cascade when it draws. What it
+caches is glyph ids, not pixels.
 
 Blank, unknown, malformed, or unsuccessful lines are ignored silently, and a
 bad line does not prevent later lines from running. Top-level text that is not