gfx: the console's typeface is replaceable, and the loader is what replaces it

Gate 0's last-but-one open item. Drop a TrueType file at \schos\console.ttf on
the ESP and the console is drawn with it; with no file, the face linked into
the kernel image, which is what an early panic needs and is not a degraded
mode.

**The loader reads it, and that is the decision worth writing down.** The
kernel opening the file once the root filesystem is mounted is the obvious
design. It is also wrong: the console has been drawing since the kernel's
first line, so a font arriving later changes the cell size, which changes the
column count, which re-lays out every terminal -- and blanks them. The kernel
log would vanish off the screen at the moment the root filesystem mounted,
which is exactly the log a machine being brought up for the first time is
being read for. Since the next thing on the list is real hardware, losing that
was not a trade worth making.

So the choice happens before anything is drawn. Three details make it cheap:

  - **EfiReservedMemoryType**, not EfiLoaderData. The E820 handoff turns
    loader data into usable memory, on the argument that the loader's own
    pages are the kernel's the moment it runs -- true of the loader, not true
    of a buffer it wants the kernel to keep reading from.
  - **Below 4 GB**, because the kernel reaches this through its direct map and
    that is how far the direct map goes. A font above it would need an ioremap
    the console cannot do before there is a console.
  - **Used in place.** No copy, which matters because the kernel has no
    contiguous allocator to copy 112 KB into -- the only one is the DMA arena,
    and that belongs to devices.

Sized without EFI_FILE_INFO and its GUID: seek past the end and ask where that
landed, which the specification requires to clamp.

Every failure falls back and keeps going -- no file, implausible size, no
memory, short read, unparseable file. The last says so in the log, because a
font that silently did not load looks exactly like a font that did.

Verified by booting with JetBrainsMono-ExtraBold.ttf on the ESP and
screendumping the console: visibly the bold face, against the Regular of a
boot with no file. Three boots each way, no traps and no panics, socktest and
memfdtest green in all six.

Nothing ships a console.ttf: the file would be the file already in the kernel,
and two copies of a font are two things that can disagree.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/plan/1.0.md

@@ -256,9 +256,21 @@ These are the galling ones — the replacement exists, is tested, and is unused.
       open. The console is a fixed grid of codepoints; `text.c`'s proportional
       path has no caller. Nothing needs this before the compositor, which is
       why it is separated from the row above rather than left blocking it.
-- [ ] **Load a font from disk** and point the console at it. The built-in one
-      is linked in on purpose — an early panic has to be readable — so this is
-      about a *replaceable* font, not about having one.
+- [x] ~~**Load a font from disk**~~ and point the console at it. The built-in
+      one is linked in on purpose — an early panic has to be readable — so this
+      is about a *replaceable* font, not about having one. Drop a TrueType file
+      at `\schos\console.ttf` on the ESP and the console is drawn with it.
+
+      **The loader reads it, not the kernel**, and that is the whole design
+      decision. The kernel could open the file once the root filesystem is
+      mounted — but the console has been drawing since long before that, so
+      switching then means re-measuring the cell and re-laying out every
+      terminal mid-boot, which wipes the kernel log off the screen at exactly
+      the moment a machine being brought up for the first time needs it. The
+      loader allocates the pages as `EfiReservedMemoryType`, so the E820
+      handoff marks them reserved, the page allocator never offers them, and
+      the kernel uses the file *in place* — no copy, and no need for a
+      contiguous allocator the kernel does not have.
 - [x] ~~**Interrupt-driven receive.**~~ The e1000's handler calls
       `netdev_rx_signal()`, which ends the network thread's wait early; the frame
       is still *pulled* by the thread, because an interrupt handler can neither