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/driver-model.md

@@ -32,7 +32,7 @@ plain bus driver with no controller — a USB hub — is also a real thing.
 
 ## The device table is the spine
 
-danos already has the right central structure. `src/kernel/device-service.zig` holds a table of
+danos already has the right central structure. `system/kernel/device-service.zig` holds a table of
 `DeviceDesc`, each with a parent, a class, and a set of resources. Firmware discovery
 seeds it ([discovery.md](discovery.md)); `device_register` grows it.
 
@@ -57,7 +57,7 @@ is not an address window. Discovery is trusted; user space is not.
 
 ### What a bus driver looks like
 
-`sbin/busd.zig` is the smallest honest one. Its "bus" is the HPET's register block and
+`system/drivers/busd/busd.zig` is the smallest honest one. Its "bus" is the HPET's register block and
 its "devices" are the block's comparators:
 
 ```zig
@@ -94,8 +94,8 @@ A "family" is two modules, not one:
 - **A protocol module** — the IPC message types that let a class driver talk to
   *whatever* published its device. This is the part that makes class drivers portable.
 
-danos already has one of each: `lib/device.zig` is a logic module,
-[`lib/vfs-protocol.zig`](lib/vfs-protocol.zig) is a protocol module shared by `sbin/vfs.zig`
+danos already has one of each: `library/runtime/device.zig` is a logic module,
+[`system/services/vfs/protocol.zig`](system/services/vfs/protocol.zig) is a protocol module shared by `system/services/vfs/vfs.zig`
 and its clients. The pattern generalises directly:
 
 ```
@@ -106,7 +106,7 @@ lib/
     pci.zig         module "pci"    — ECAM, BAR decode, capability walk
     usb.zig         module "usb"    — descriptors, control transfers, hubs
   proto/
-    vfs.zig         module "proto.vfs"    (today: lib/vfs-protocol.zig)
+    vfs.zig         module "proto.vfs"    (today: system/services/vfs/protocol.zig)
     block.zig       module "proto.block"
     hid.zig         module "proto.hid"
 
@@ -183,7 +183,7 @@ const dev_ep = ipc.callCap(h,            //   ... mint a per-device endpoint,
 **The blocker.** An HCD is a DMA-engine programmer. It needs a descriptor ring the
 device can read, which means memory that is (a) physically contiguous, (b) at a
 physical address the driver knows, (c) of the right cacheability, and (d) pinned.
-[`sysMmap`](src/kernel/process.zig) gives you *none* of the four: it calls `pmm.alloc()`
+[`sysMmap`](system/kernel/process.zig) gives you *none* of the four: it calls `pmm.alloc()`
 once per page, maps writeback-cached, and never reveals a physical address.
 
 **The fix.**
@@ -217,7 +217,7 @@ doorbell.* = i;             // volatile store to UC MMIO
 // nothing stops the compiler reordering these; the device reads a stale descriptor
 ```
 
-So the rules, which belong in `lib/mmio.zig` and behind `arch`:
+So the rules, which belong in `library/mmio.zig` and behind `arch`:
 
 | Situation | Required |
 |---|---|
@@ -241,12 +241,12 @@ with a compiler barrier alone. ARM is not, and [vision.md](vision.md) makes ARM
 condition. Build the abstraction while there is one caller to fix.
 
 (Zig note: `@fence` was **removed in 0.16**. Use `@atomicRmw(..., .seq_cst)` for a full
-barrier, or per-arch inline asm — which is what `lib/mmio.zig` should hide.)
+barrier, or per-arch inline asm — which is what `library/mmio.zig` should hide.)
 
 ## M15 — interrupts for PCI devices
 
 **The blocker, and it's a hard one.** No PCI device can take an interrupt today.
-[`addBars`](src/device/acpi.zig) records `.memory` and `.io_port` BARs and never an
+[`addBars`](system/devices/acpi.zig) records `.memory` and `.io_port` BARs and never an
 `.irq`; there is no `_PRT` parsing anywhere in the tree. `hpetd` only works because the
 HPET advertises its own routing options in its own registers — a privilege no ordinary
 device has.