include: one folder per subsystem, and includes that name it

Sixty-five headers sat side by side in include/, so `#include "irq.h"`
said nothing about where irq.h was or what it belonged to, and errno.h,
stat.h and fcntl.h at the top shadowed the system's for any host tool
built with -I./include. They are in folders now -- arch/ core/ fs/
dev/ gfx/ net/ uapi/ (and ldls/ for the Linux driver layer) -- and
every include names the folder, as Linux's do: "core/proc.h".

Done mechanically and checked the hard way: the kernel built from this
tree disassembles identically to the one built from the tree before
it. The full image boots, and userland is the same set of programs.
Paths in docs and comments follow; docs/guides/layout.md has a table
of what is where, and tools/fix-includes.py rewrites old-style
includes from the folders in the tree, for code written before this.

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

docs/plan/1.0.md

@@ -256,7 +256,7 @@ These are the galling ones — the replacement exists, is tested, and is unused.
       rest of it retired — which needs explaining, because the item as written
       asked for something a terminal cannot be.
 
-      `include/text.h` made the case against the grid in four charges: it
+      `include/gfx/text.h` made the case against the grid in four charges: it
       cannot do variable-width glyphs, cannot position text off a multiple of
       eight, cannot anti-alias, and cannot hold a codepoint above 255. **All
       four were about the drawing layer, and all four are now false** — glyphs

docs/plan/hybrid.md

@@ -45,7 +45,7 @@ the one that survives contact with a real machine.
 
 ## Built so far
 
-**Mechanisms 2 and 4 exist.** `/dev/pci` (include/pciuser.h, kernel/dev/pciuser.c)
+**Mechanisms 2 and 4 exist.** `/dev/pci` (include/dev/pciuser.h, kernel/dev/pciuser.c)
 enumerates the bus, hands a device to a process exclusively, maps a BAR into it
 and allocates memory a device can be pointed at. `pcitest` proves it end to end:
 
@@ -378,7 +378,7 @@ a panic, so the process holding the device is never going to run again, and the
 kernel let go of the device deliberately.
 
 **So the userspace driver says in advance where it is scanning out**, with
-`PCIIOC_PANICFB` (see `include/pciuser.h`), and the kernel does the rest:
+`PCIIOC_PANICFB` (see `include/dev/pciuser.h`), and the kernel does the rest:
 
 1. paints the report into that memory,
 2. asks the *kernel* driver the device was taken from to put it on screen —