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.

system/services/vfs/protocol.zig

@@ -0,0 +1,53 @@
+//! The VFS wire protocol — the message format spoken between a client (via the
+//! `runtime` file API) and the user-space VFS server over IPC. A request is a fixed
+//! `Request` header followed by an inline payload (a path, or write bytes); a
+//! reply is a fixed `Reply` header followed by an inline payload (read bytes, or
+//! a Stat). Everything fits in one IPC message (<= ipc MESSAGE_MAXIMUM = 256 bytes).
+//!
+//! This is user-space only — the kernel knows nothing of files or paths; it only
+//! moves the bytes. Shared by library/runtime/unistd.zig (client) and system/services/vfs/vfs.zig (server).
+
+pub const Operation = enum(u32) {
+    open, // open(path) -> node id
+    close, // close(node)
+    read, // read(node, offset, len) -> bytes
+    write, // write(node, offset, bytes) -> count
+    stat, // stat(node) -> Stat
+};
+
+/// Request header. `node` is the server-side open-file id (from a prior open);
+/// for `open` the path is the payload and `len` is its length. `offset`/`len`
+/// carry the read/write position and count.
+pub const Request = extern struct {
+    operation: Operation,
+    node: u64,
+    offset: u64,
+    len: u32,
+    flags: u32,
+};
+
+/// Reply header. `status` is 0 on success or a negative errno; `node` is the new
+/// open-file id (for `open`); `len` is the payload length (bytes read, or the
+/// Stat size).
+pub const Reply = extern struct {
+    status: i32,
+    _padding: u32 = 0,
+    node: u64 = 0,
+    len: u32 = 0,
+    _padding2: u32 = 0,
+};
+
+pub const Stat = extern struct {
+    size: u64,
+    kind: u32,
+    _padding: u32 = 0,
+};
+
+pub const message_maximum: usize = 256;
+pub const request_size: usize = @sizeOf(Request);
+pub const reply_size: usize = @sizeOf(Reply);
+/// Largest inline payload that still fits one IPC message alongside a header.
+pub const maximum_payload: usize = message_maximum - request_size;
+
+/// Open flags.
+pub const O_CREAT: u32 = 1;