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.