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

@@ -8,15 +8,15 @@ concern, not an afterthought.
 
 There are two layers, built a milestone apart:
 
-- **`src/kernel/ipc.zig`** — a bounded blocking channel between *kernel threads*,
+- **`system/kernel/ipc.zig`** — a bounded blocking channel between *kernel threads*,
   described below. The primitive, and where the blocking discipline was worked out.
-- **`src/kernel/ipc-synchronous.zig`** — synchronous call/reply between *processes*, across
+- **`system/kernel/ipc-synchronous.zig`** — synchronous call/reply between *processes*, across
   address spaces. What user-space servers and drivers actually talk over. It's the
   second half of this document.
 
 ## The channel
 
-The first form is a **bounded blocking channel** (`src/kernel/ipc.zig`): a fixed-size
+The first form is a **bounded blocking channel** (`system/kernel/ipc.zig`): a fixed-size
 ring buffer of messages with a producer/consumer rendezvous, built on the
 scheduler's [wait queues](scheduling.md).
 
@@ -54,7 +54,7 @@ expected `5050`), and neither task busy-waits — they block and wake each other
 
 A channel connects two kernel threads sharing one address space. Real servers are
 *processes*, so the payload has to cross an address-space boundary. That's
-`src/kernel/ipc-synchronous.zig`, and its shape is L4's: a synchronous **rendezvous** at an
+`system/kernel/ipc-synchronous.zig`, and its shape is L4's: a synchronous **rendezvous** at an
 `Endpoint`, with the message copied directly from the sender's pages to the receiver's
 (`copyAcross` walks both sets of page tables through the physmap — no CR3 switch, no
 bounce buffer).