debugger: reachable from the console, and named on the crash screen

Two things, both about the debugger being available at the moment you
actually need it rather than once a shell exists.

**Ctrl-G on the console runs every view.** No filesystem, no /dev, no
shell -- it is the last thing main() sets up before entering the scheduler,
so it answers from early in boot, which is exactly when boot problems
happen. It sits beside the older Ctrl-P, and the difference between them is
the interesting part: procdump() takes no lock at all, deliberately,
because a lock is a way to hang while reporting a hang. The views cannot
follow that rule -- a free list read torn is worse than not read -- so they
take locks, and a lock must never be taken from an interrupt handler that
may have interrupted its holder. The key therefore *requests* and a kernel
thread *performs*. A scheduler too wedged to run a thread will not answer
Ctrl-G; Ctrl-P still will, and that division is the honest one.

**PSOGM says where the report went.** Its closing line used to be an
addr2line command, which the call chain no longer needs -- it prints names
now. What replaced it is the thing nobody would guess:

    This report is in /proc/kmsg after a restart.
    schdbg, or Ctrl-G on the console, asks more.
    PSOGM  --  Purple Screen of Guru Meditation

"Restart and read it" beats "photograph this screen" by a wide margin, and
until the log outlived the kernel it was not true. Both panic.c and
graphics.md had claimed in writing that the screen was the only artefact of
a crash; neither says so now. The QR code stays, because it is still the
only channel that works when the machine will not come back at all.

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

docs/architecture/debugging.md

@@ -200,10 +200,24 @@ fine.
 
 | | Works when |
 |---|---|
-| `sysrq g` | always — every view to the console, no process, no filesystem, no client program |
-| `/dev/dbg` | there is a scheduler and a filesystem |
+| **Ctrl-G** on the console | there is a scheduler — so from early in boot, with nothing mounted and nothing in userspace started |
+| `sysrq g` | `/proc` is mounted |
+| `/dev/dbg` | `/dev` is mounted |
 | `schdbg` | there is a shell |
 
+**Ctrl-G is the one that matters for boot problems**, because it is the only
+one that does not need a filesystem. It sits beside the older Ctrl-P, which
+dumps the process table — and the difference between them is worth knowing.
+`procdump()` takes **no lock at all**, deliberately: a lock is a way to hang
+while reporting a hang. The views cannot follow that rule, because a free list
+or a socket table read torn is worse than not read. So they take locks, and a
+lock must never be taken from an interrupt handler that may have interrupted
+its holder.
+
+The key therefore *requests* and a kernel thread *performs*. The cost is stated
+plainly: a scheduler too wedged to run a thread will not answer Ctrl-G. Ctrl-P
+still will, and that division of labour is the honest one.
+
 A watchpoint's *hits* go to the console rather than to any of these, because
 they happen while you are not looking, which is the point of having them.
 
@@ -342,6 +356,10 @@ something that reports nonsense.
   watchpoint on something `cprintf` itself writes is silently dropped rather
   than looping; the handler guards against re-entering itself per CPU.
 - **A watchpoint takes up to one timer tick** to reach the other CPUs.
+- **Ctrl-G needs a working scheduler**, per the note above. Before
+  `dbg_thread_start()` — which is the last thing `main()` does before entering
+  the scheduler — nothing answers but the log, and the log is enough because it
+  is read on the *next* boot.
 - **No network transport.** The plan puts a TCP bridge in a userspace daemon,
   deliberately outside the kernel; it does not exist, so the debugger is local
   or serial only.

docs/architecture/graphics.md

@@ -179,17 +179,36 @@ you it stopped — which is both truer and much less alarming.
 face that is obviously a cartoon, then the facts. Whoever is reading this is
 already having a bad time.
 
-**It says considerably more than it needs to.** The screen is the only artefact
-of a panic — no core dump, no log to go back to — so everything cheap to collect
-is collected: stop code, fault address, which CPU, which process, how far into
-the boot, where the kernel is loaded, and a call chain. Anything left out is
-gone. All of it goes to the serial line in the same order, which is what
-`bootcheck` reads and what you get when the crash happens before there is a
-framebuffer at all.
+**It says considerably more than it needs to.** Everything cheap to collect is
+collected: stop code, fault address, which CPU, which process, how far into the
+boot, where the kernel is loaded, and a call chain — and since
+[debugging.md](debugging.md)'s symbol table, the call chain is *names*:
+`panic+0x5f`, `proc_sysrq_cmd+0xb3`, `sys_writev+0x12b`. All of it goes to the
+serial line in the same order, which is what `bootcheck` reads and what you get
+when the crash happens before there is a framebuffer at all.
 
 Once painted, `panicked` is set and `consputc` spins rather than writing, so
 nothing can scribble over the report.
 
+### It is no longer the only copy
+
+This screen used to be the only artefact of a panic — this file said so, and so
+did `panic.c`'s own header. That stopped being true when the kernel log started
+outliving the kernel, and the closing lines changed to match:
+
+```
+This report is in /proc/kmsg after a restart.
+schdbg, or Ctrl-G on the console, asks more.
+PSOGM  --  Purple Screen of Guru Meditation
+```
+
+The first line replaced an `addr2line` command, which the call chain no longer
+needs. It is the more useful instruction by a wide margin, and it is the one
+nobody would guess: **restart and read it** beats photographing the screen.
+
+The QR code below is still drawn, and still earns its place — it is the only
+channel that works when the machine will not come back at all.
+
 ### The QR code
 
 `kernel/core/qr.c`. **A panic report is worth nothing if it cannot leave a