docs: document the supervision hierarchy and driver discovery

drivers.md gains a "How a driver gets started" section — the doc explained what a
running driver does but never who starts it. It lays out the three-level supervision
hierarchy (kernel spawns init; init spawns the services; the device-manager discovers,
matches, and spawns the drivers) and names the two user-space policies that "configure"
drivers today: init's service list and the device-manager's match table.

driver-model.md's "what exists today" adds system_spawn and the supervision model, and
the drivers.md restart bullet is refreshed: a spawning supervisor now exists, a
restarting one still doesn't.

docs/driver-model.md

@@ -132,9 +132,15 @@ If a class driver needs `mmio`, it has become an HCD and should be one.
 - **M11** — `irq_bind` / `irq_ack`. IRQ delivered as an IPC notification; mask before
   EOI; `irq_ack` is the unmask.
 - **M12** — `parent` in `DeviceDesc`, `device_register` with resource containment.
+- **`system_spawn`** — a user-space supervisor starts a driver: `system_spawn(name)`
+  loads a binary bundled in the initial-ramdisk as a fresh ring-3 process. This is what
+  turned the device manager from "log the match" into "run the driver": the kernel now
+  spawns only `init`, `init` spawns the services, and the **device-manager** discovers
+  the hardware and spawns each driver ([drivers.md](drivers.md)). Ungated for now — a
+  spawn capability is future work.
 
-So: **bus drivers work now.** HCDs and class drivers do not. Here is exactly why, and
-exactly what would fix it.
+So: **bus drivers work now, and they're started by the device manager, not the kernel.**
+HCDs and class drivers do not work yet. Here is exactly why, and exactly what would fix it.
 
 ---