Re-organize the source tree as a monorepo mirroring the FHS

The source layout now mirrors the runtime filesystem hierarchy
(docs/danos-file-system-hierarchy-FSH.md): what lives under system/ in the
source is what a running danos represents under /system. Each service and
driver is a sub-project directory that is its own Zig module — cross-project
references go by module name, never by a path into another project's files.

Moves (all git mv, history preserved):
- src/            -> system/            (danos internals; the self-representation)
    root.zig      -> danos.zig          (the kernel<->user contract module)
    kernel/arch/  -> kernel/architecture/   (arch -> architecture)
    device/       -> devices/           (what /system/devices reflects)
    boot/         -> /boot              (the loaders, top level)
- sbin/           -> split by role:
    init, vfs     -> system/services/<name>/<name>.zig
    hpetd, busd   -> system/drivers/<name>/<name>.zig
    vfs-test      -> system/services/vfs/vfs-test.zig  (inside the vfs project)
- lib/            -> library/runtime/   (room for other libraries beside runtime)

The VFS wire protocol becomes its own module, system/services/vfs/protocol.zig
("vfs-protocol"): the vfs sub-project exposes its interface, and the runtime's
file layer imports it by name. First instance of the "protocol module" pattern
(docs/driver-model.md); usb/block will expose theirs the same way.

Also: fix a naming-standard violation in the protocol — Op -> Operation (and
req -> request, _pad -> _padding). Docs updated: /system/services added to the
FHS doc, a repository-layout section added to the docs index, and stale source
paths swept across comments and docs.

Runtime boot paths are unchanged (the bootloader still loads /sbin/init);
aligning the runtime filesystem to the FHS is a separate follow-up. Suite 35/35
plus host tests green.

docs/arch.md

@@ -13,7 +13,7 @@ runtime dispatch. `build.zig` exposes one architecture's code as a module called
 
 ```zig
 const arch_mod = b.addModule("arch", .{
-    .root_source_file = b.path("src/kernel/arch/x86_64/cpu.zig"),
+    .root_source_file = b.path("system/kernel/architecture/x86_64/cpu.zig"),
 });
 ```
 
@@ -26,7 +26,7 @@ arch.halt();          // never says "x86_64"
 ```
 
 Adding a second architecture is then a build-time choice: create
-`src/kernel/arch/aarch64/`, and point the `arch` module at it when the target CPU is
+`system/kernel/arch/aarch64/`, and point the `arch` module at it when the target CPU is
 AArch64. `main.zig` and `console.zig` don't change. **That compiler-checked module
 boundary _is_ the architecture interface** — when a new arch is missing a function
 the generic kernel calls, the build fails and names exactly what's missing.
@@ -36,7 +36,7 @@ the generic kernel calls, the build fails and names exactly what's missing.
 The split follows a simple test: does it name a CPU instruction, a hardware
 register, or a memory-management structure? If so, it's arch-specific.
 
-| Arch-specific — `src/kernel/arch/x86_64/` | Generic — kernel core |
+| Arch-specific — `system/kernel/architecture/x86_64/` | Generic — kernel core |
 |---|---|
 | `cpu.zig`: `halt()` (`hlt`), later GDT/IDT/paging | `console.zig` — pure pixel math, works anywhere |
 | `linker.ld` — link layout, load address | `main.zig` — `kmain` orchestration, panic handler |
@@ -51,9 +51,9 @@ should end up on the generic side; the arch module stays small.
 There are really two independent questions, and it's worth not conflating them:
 
 - **CPU architecture** (x86_64 vs AArch64): instructions, MMU, interrupts →
-  `src/kernel/arch/<cpu>/`.
+  `system/kernel/arch/<cpu>/`.
 - **Boot protocol** (UEFI vs Raspberry Pi firmware + device tree): handled
-  *separately*, because loaders are their own binaries. `src/boot/efi.zig` builds
+  *separately*, because loaders are their own binaries. `boot/efi.zig` builds
   `BOOTX64.efi`, a distinct executable from the kernel ELF. On a Pi there is no
   separate loader at all — the firmware jumps straight into the kernel with a
   device-tree pointer, so that entry work would live in the AArch64 arch code.
@@ -61,24 +61,24 @@ There are really two independent questions, and it's worth not conflating them:
 
 ## Current x86_64 contents
 
-- **`src/kernel/arch/x86_64/cpu.zig`** — the `arch` module root. Exposes `halt()` (see
+- **`system/kernel/architecture/x86_64/cpu.zig`** — the `arch` module root. Exposes `halt()` (see
   [halting.md](halting.md)), `init()` (bring up the descriptor tables),
   `enablePaging()`, `setFaultHandler`, `readCr2`/`readCr3`, and the `CpuState`
   trap frame.
-- **`src/kernel/arch/x86_64/gdt.zig`** / **`idt.zig`** / **`tss.zig`** — the GDT, IDT and
+- **`system/kernel/architecture/x86_64/gdt.zig`** / **`idt.zig`** / **`tss.zig`** — the GDT, IDT and
   TSS plus CPU-exception handling (see [interrupts.md](interrupts.md)).
-- **`src/kernel/arch/x86_64/paging.zig`** — the kernel's page tables (see
+- **`system/kernel/architecture/x86_64/paging.zig`** — the kernel's page tables (see
   [paging.md](paging.md)).
-- **`src/kernel/arch/x86_64/apic.zig`** — the Local APIC and its timer, the source of
+- **`system/kernel/architecture/x86_64/apic.zig`** — the Local APIC and its timer, the source of
   device interrupts (see [device-interrupts.md](device-interrupts.md)).
-- **`src/kernel/arch/x86_64/serial.zig`** / **`io.zig`** — the COM1 UART (the kernel's
+- **`system/kernel/architecture/x86_64/serial.zig`** / **`io.zig`** — the COM1 UART (the kernel's
   machine-readable log channel, see [testing.md](testing.md)) and the shared
   port-I/O + MSR primitives.
-- **`src/kernel/arch/x86_64/isr.s`** — the exception stubs, the `lgdt`/`lidt`/`ltr` load
+- **`system/kernel/architecture/x86_64/isr.s`** — the exception stubs, the `lgdt`/`lidt`/`ltr` load
   helpers, and the context switch (`switch_context` / `task_trampoline`, see
   [scheduling.md](scheduling.md)) — real assembly, since Zig inline asm can't
   express them.
-- **`src/kernel/arch/x86_64/linker.ld`** — the kernel link layout (fixed low load
+- **`system/kernel/architecture/x86_64/linker.ld`** — the kernel link layout (fixed low load
   address, one PT_LOAD per permission set).
 
 The kernel entry point `_start` currently still lives in the generic `main.zig` as