Device manager (increment 3): the kernel stops spawning the bundle

Retire the kernel's spawn-every-initial-ramdisk-binary loop, resolving the
service/driver split into a real three-level supervision hierarchy:

  kernel  -> spawns init (PID 1) only, and publishes the initial-ramdisk
  init    -> the service supervisor: spawns the system services (vfs, device-manager)
  device-manager -> spawns the drivers it matches (hpet)

The kernel now only hands the initial-ramdisk image to the process layer
(publishInitialRamdisk) so user space can system_spawn from it; it launches nothing
bundled itself. init gains a boot-services list ("vfs", "device-manager") and spawns
them best-effort before settling into its heartbeat — policy lives in user space,
where a microkernel keeps it. Drivers are absent from that list on purpose: the
device manager owns them. Test-only binaries (vfs-test, bus) no longer run at boot;
their kernel self-tests still spawn them directly.

This removes increment 2's transitional double-spawn: a real boot now brings hpet up
exactly once (verified — kernel -> init -> vfs/device-manager -> hpet, zero "claim
failed"). The automated suite is unaffected: test builds run their case and halt
before the normal boot path, so each already spawns its own binaries. Suite 36/36
plus host tests; normal boot verified by hand under QEMU.

system/services/init/init.zig

@@ -4,14 +4,21 @@
 //! kernel (system/kernel/process.zig). It links against the shared user runtime
 //! library `runtime` and talks to the kernel only through `runtime`'s system_call wrappers.
 //!
-//! Today it proves the C-convention heap works, then settles into a heartbeat:
-//! it prints a line and sleeps, forever — enough to show the system reaches user
-//! space and stays alive with a real process scheduled alongside the kernel's
-//! idle loop. It grows into the real init (service supervision) once there are
-//! other user programs to supervise.
+//! It proves the C-convention heap works, then — as PID 1 — acts as the system's
+//! **service supervisor**: it spawns the user-space services danos brings up at boot
+//! (the VFS server, the device manager), and settles into a heartbeat so it stays
+//! alive as the root of user space. Drivers are *not* its job: the device manager
+//! discovers the hardware and spawns those. This is the service half of the
+//! service/driver spawn split (docs/driver-model.md).
 
 const runtime = @import("runtime");
 
+/// The system services init brings up at boot, in order. This is init's policy — the
+/// microkernel keeps such choices in user space, not the kernel. Drivers are absent
+/// on purpose: the device manager owns those. (A future init reads this from a
+/// manifest under /system/services instead of a hardcoded list.)
+const boot_services = [_][]const u8{ "vfs", "device-manager" };
+
 pub fn main() void {
     // Prove the heap end to end: allocate through the runtime allocator (which
     // mmaps pages from the kernel and carves them with the free list), write into
@@ -27,6 +34,13 @@ pub fn main() void {
         gpa.free(buffer);
     } else |_| {}
 
+    // Bring up the boot services. Best-effort and silent: each service announces its
+    // own readiness (`vfs: ready`, ...), and in an isolation test that runs init with
+    // no initial-ramdisk the spawns simply no-op rather than deranging the heartbeat.
+    for (boot_services) |service| {
+        _ = runtime.system.spawn(service);
+    }
+
     while (true) {
         _ = runtime.system.write("init: heartbeat\n");
         runtime.system.sleep(1000);