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/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