virtio-gpu: the scanout device arrives with the spawn

Third driver converted. It no longer claims the id from argv[1] — the
manager holds the device and names it in the call that creates the process,
so it is held before the driver's first instruction.

display-reattach is the case that matters here: it kills the driver and
watches the compositor re-attach to the fresh scanout. It passes, so the
restart path survives the fused grant — the manager re-takes the device when
the driver dies and hands it to the replacement.

ps2-bus and discovery are NOT converted, and the reason is recorded as open
question 9 rather than worked around. Both need a device nobody assigned
them. ps2-bus ignores its argv[1] entirely: it finds the controller by
walking the table for PNP0303, then claims a second device, the PNP0F13
mouse node, which it also finds itself — so it holds two devices and was
assigned at most one, while system_spawn carries one. discovery claims the
acpi-tables node it locates itself, because it is what produces the device
tree and there is nothing to assign at that point.

One thing worth checking before designing an answer: devices.csv maps both
PS/2 hardware ids to ps2-bus, so the manager may already be spawning two
instances where the driver expects one. If so the fix is smaller than it
looks.

D6 stays blocked — closing device_claim with these two still depending on it
would stop the machine booting.

Suite 118/118.

docs/bounds-track-plan.md

@@ -43,7 +43,7 @@ that cannot safely run in user space.**
 | D2 | Adversarial case: a process handed nothing is refused, on a held device and a free one | **done** — `device-authority-test`; the claim half joins it at D6 |
 | D3 | The manager claims the seeded devices at boot, before any driver is spawned | **merged into D4** — see below |
 | D4 | The manager claims + delegates on `hello`; `usb-xhci-bus` is the first driver converted | **done** — caught an IOMMU regression I introduced; see below |
-| D5 | The other four claimants converted: `pci-bus`, `ps2-bus`, `virtio-gpu`, `acpi` | **partial** — `pci-bus` done; the rest unblocked by D0 below |
+| D5 | The other four claimants converted: `pci-bus`, `ps2-bus`, `virtio-gpu`, `acpi` | **partial** — `pci-bus` + `virtio-gpu` done; `ps2-bus` and discovery need question 9 |
 | D0 | The grant rides `system_spawn` — atomic, so no driver need change to receive one | **done** — and caught a test-marker bug that made the D2 fixture unfailable |
 | D10 | Every driver hellos, on its own merits (liveness, one class of driver) | not started — optional, independent |
 | D6 | `device_claim` refuses a device the caller was not handed; the hole is closed | not started |
@@ -87,6 +87,35 @@ They land together, with the manager claiming only for drivers in an explicit
   anything in D4 — recorded rather than dismissed, because D4 moved the `hello` earlier
   and so did shift boot timing. Watch it across the remaining steps.
 
+### Open question 9 — two drivers need a device nobody assigned them
+
+D0 made delivery atomic and D5 converted `virtio-gpu` with it. The last two do not fit,
+for the same underlying reason: **they need a device the manager never assigned.**
+
+- **`ps2-bus` ignores its `argv[1]` entirely.** It finds the controller by walking the
+  table for `PNP0303`, and then claims a *second* device — the `PNP0F13` mouse node —
+  which it also finds itself. So it holds two devices and was assigned at most one, and
+  `system_spawn` carries one.
+- **discovery** is spawned `addDriver("discovery", no_device, false)` and claims the
+  `acpi-tables` node it locates itself, because it is what produces the device tree;
+  there is nothing to assign at that point.
+
+Three shapes of answer, none written down:
+
+1. **The manager assigns every device a driver needs.** For `ps2-bus` it would have to
+   understand that one driver serves both `PNP0303` and `PNP0F13` — `devices.csv` maps
+   both to it already, so the manager may simply be spawning two instances today where
+   the driver expects one. Worth checking before designing.
+2. **A driver asks for a device over the protocol** — a `request(device)` verb the
+   manager answers by transferring. General, and it reintroduces a window, though only
+   for a device the driver asks for after it is running.
+3. **The bootstrap is exempt**: discovery keeps claiming, and D6 permits a claim of a
+   device nobody holds *only* for the discovery role. Narrow and honest, but it is an
+   exception in the exact place an exception is most expensive.
+
+**D6 stays blocked** until this is answered — closing `device_claim` with these two
+still depending on it would stop the machine booting.
+
 ### Settled 2026-08-08: the grant rides `system_spawn` (D0)
 
 Questions 6 and 7 both dissolved on inspection — neither `ps2-bus` nor discovery needs

system/drivers/virtio-gpu/virtio-gpu.zig

@@ -200,10 +200,9 @@ fn testPixel(index: u32) u32 {
 
 fn initialise(endpoint: ipc.Handle) bool {
     _ = endpoint;
-    device.claim(device_id) catch |e| {
-        std.log.info("unable to claim device {d}: {s}", .{ device_id, @errorName(e) });
-        return false;
-    };
+    // The device arrived with the spawn — the manager holds it and names it in the call
+    // that creates this process, so it is ours before the first instruction here
+    // (docs/os-development/device-authority.md). Nothing to claim.
 
     var descriptors: [64]device.DeviceDescriptor = undefined;
     const total = device.enumerate(&descriptors);

system/services/device-manager/device-manager.zig

@@ -248,6 +248,7 @@ fn alreadySupervised(name: []const u8) bool {
 const delegated_drivers = [_][]const u8{
     "usb-xhci-bus",
     "pci-bus",
+    "virtio-gpu",
 };
 
 /// Matched on the **last path component**, because a driver reaches this table under