Make zig-out a FHS image, and the boot volume

`zig build` now installs into a FHS-shaped zig-out that *is* the danos filesystem
and the boot volume — no more zig-out/bin or a separate esp/:

  zig-out/EFI/BOOT/BOOTX64.efi        (firmware entry; UEFI fixes this path)
  zig-out/boot/initial-ramdisk.img
  zig-out/system/kernel               (the kernel binary)
  zig-out/system/services/init  vfs
  zig-out/system/drivers/hpet   bus

Binaries land at their addressed, leaf-collapsed paths per the sub-project
resolution rule (system/services/init/init.zig -> system/services/init); vfs, hpet,
and bus are installed to their FHS homes too, so the image is complete even though
at boot they arrive inside the initial-ramdisk.

The bootloader (boot/efi.zig) now loads each artifact from its FHS path
(system\kernel, system\services\init, boot\initial-ramdisk.img); run-x86-64 mounts
zig-out directly; the QEMU test harness assembles its ESP from the FHS zig-out.

Also renames system/kernel/main.zig -> kernel.zig so the kernel follows the
name/name.zig convention (kernel/ = ring-0 code, services/ = ring-3 OS services).
Documents the resolution rule in the repository-layout section (README + coding
standard). Suite 35/35 plus host tests green.

docs/efi.md

@@ -20,14 +20,17 @@ UEFI boots by looking for a FAT-formatted partition called the **EFI System
 Partition (ESP)** and running a file at a well-known fallback path:
 
 ```
-esp/EFI/BOOT/BOOTX64.efi     <- the "removable media" default for x86-64
+EFI/BOOT/BOOTX64.efi         <- the "removable media" default for x86-64
 ```
 
-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.
-The firmware finds `BOOTX64.efi` and runs it — that's our `main()`.
+The boot volume is the **FHS-shaped `zig-out`** itself (see the repository-layout note
+in [README.md](README.md)): `build.zig` installs `boot/efi.zig` (built for the `uefi`
+target) to `zig-out/EFI/BOOT/BOOTX64.efi` — the one path UEFI firmware fixes — and lays
+the rest out by FHS path: the kernel at `zig-out/system/kernel`, init at
+`zig-out/system/services/init`, the initial-ramdisk at `zig-out/boot/`. The
+`run-x86-64` step points QEMU at OVMF (UEFI firmware for virtual machines) and presents
+`zig-out` to the guest as a FAT drive. The firmware finds `BOOTX64.efi` and runs it —
+that's our `main()`, which then loads the kernel and init from their FHS paths.
 
 ## Boot services: the firmware's API
 
@@ -164,13 +167,13 @@ the loader writes are the bytes the kernel reads.
 ```
 power on
   -> UEFI firmware initialises hardware
-  -> finds esp/EFI/BOOT/BOOTX64.efi, runs it        (our efi.zig main)
+  -> finds EFI/BOOT/BOOTX64.efi on the FHS volume, runs it   (our efi.zig main)
        -> grab boot services
        -> queryFramebuffer   (via GOP: EDID native res, setMode, describe fb)
-       -> loadKernel         (read danos ELF, load PT_LOAD segments to 0x100000)
+       -> loadKernel         (read system/kernel 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           (system/kernel/main.zig: framebuffer console, then halt)
+  -> kernel _start           (system/kernel/kernel.zig: framebuffer console, then halt)
 ```
 
 Bottom line: **UEFI's job is to give us a CPU, memory, and a framebuffer, then