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/efi.md

@@ -10,7 +10,7 @@ that hands us a working CPU, a memory map, and a screen, and then gets out of th
 way.
 
 The key thing to understand: **UEFI is not our OS, it's a stepping stone.** It
-exists to load *us*. Our `src/boot/efi.zig` is a UEFI *application* — a normal program
+exists to load *us*. Our `boot/efi.zig` is a UEFI *application* — a normal program
 that the firmware runs — and its entire purpose is to gather what the kernel needs
 and then jump into the kernel.
 
@@ -23,7 +23,7 @@ Partition (ESP)** and running a file at a well-known fallback path:
 esp/EFI/BOOT/BOOTX64.efi     <- the "removable media" default for x86-64
 ```
 
-That's exactly the layout `build.zig` assembles. It builds `src/boot/efi.zig` for the
+That's exactly the layout `build.zig` assembles. It builds `boot/efi.zig` for the
 `uefi` target, installs it to `esp/EFI/BOOT/BOOTX64.efi`, and drops the kernel ELF
 at `esp/kernel`. The `run-x86-64` step then points QEMU at OVMF (UEFI firmware for
 virtual machines) and presents that `esp/` directory to the guest as a FAT drive.
@@ -139,7 +139,7 @@ kernel is freestanding and uses the **SysV AMD64** convention (first argument in
 read garbage.
 
 So both sides pin the convention explicitly to SysV via the shared
-`danos.kernel_abi` (defined in `src/root.zig`). The loader's function-pointer type
+`danos.kernel_abi` (defined in `system/danos.zig`). The loader's function-pointer type
 and the kernel's `_start` both reference it, so the pointer lands in the register
 the kernel expects. This is the whole reason `kernel_abi` lives in the shared
 `danos` module: it's a contract both binaries must agree on. See
@@ -149,7 +149,7 @@ the kernel expects. This is the whole reason `kernel_abi` lives in the shared
 
 The loader and kernel are two *separate* binaries built for two different targets,
 so everything they exchange must have an identically-defined memory layout. That's
-what `src/root.zig` provides — imported by both as the `danos` module:
+what `system/danos.zig` provides — imported by both as the `danos` module:
 
 - `BootInfo` — the top-level struct passed to the kernel (currently just the
   framebuffer; this is where future handoff data like the memory map will go).
@@ -170,10 +170,10 @@ power on
        -> loadKernel         (read danos ELF, load PT_LOAD segments to 0x100000)
        -> exitBootServices   (retry until the memory-map key holds)
        -> jump to e_entry, boot_info pointer in RDI
-  -> kernel _start           (src/kernel/main.zig: framebuffer console, then halt)
+  -> kernel _start           (system/kernel/main.zig: framebuffer console, then halt)
 ```
 
 Bottom line: **UEFI's job is to give us a CPU, memory, and a framebuffer, then
-disappear.** `src/boot/efi.zig` is the thin bridge that collects those gifts into a
+disappear.** `boot/efi.zig` is the thin bridge that collects those gifts into a
 `BootInfo`, tears down the firmware, and jumps into the kernel — after which we're
 on our own.