Device manager (increment 1): discover + match

The device manager is the ring-3 process that turns the device tree into a running
system — the udev-analog. It is mechanism-vs-policy done right: the kernel
enumerates the hardware and enforces the claim capability; this decides which
driver serves which device, using no special privilege (the same device_enumerate
any process could call).

This first increment does the discovery + matching half: system/services/
device-manager enumerates /system/devices, matches each device to a driver by
class (a small static policy table), and logs the decision — finding the HPET
(a timer) and deciding `hpet` serves it. It does not spawn yet: spawning needs a
`system_spawn` system call (the kernel spawns every initial-ramdisk binary in a
loop today), which is the next increment. New `device-manager` test; suite 36/36
plus host tests.

test/qemu_test.py

@@ -197,6 +197,12 @@ CASES = [
     {"name": "hpet",
      "expect": r"DANOS-TEST-RESULT: PASS",
      "fail":   r"DANOS-TEST-RESULT: FAIL"},
+    # Device manager: a ring-3 service enumerates /system/devices and matches each
+    # device to a driver (discovery + policy in user space). This increment logs the
+    # decision; spawning follows.
+    {"name": "device-manager",
+     "expect": r"DANOS-TEST-RESULT: PASS",
+     "fail":   r"DANOS-TEST-RESULT: FAIL"},
     # Bus driver: a user process claims a device, enumerates its children from the
     # hardware, and publishes each with dev_register — and the kernel refuses a child
     # whose window escapes the parent's (else dev_register maps arbitrary memory).