docs: there is no virtio-gpu standalone bring-up to lose

Question 7 read the comment "Best-effort: standalone bring-up has no
manager" as a boot path that delegation would delete. It is not one.
virtio-gpu's main requires argv[1] and exits without it, and the only source
of that argument is the device manager: ACPI, then pci-bus reports the
function, then devices.csv matches 1AF4:1050, then the manager spawns the
driver with the id. Without a manager the driver prints and returns, and
never reaches the hello at all.

The comment is about resilience, not boot: the hello is best-effort so a
driver whose manager has died keeps serving, which device-manager.md states
outright.

So the question dissolves. The residual is one narrow window — the manager
spawns a driver and dies before transferring — where today the driver could
still claim because claiming is free-for-all, and after D6 it would exit for
the restarted manager to respawn. That is the better behaviour: a driver
holding hardware nobody assigned it is exactly what D6 exists to stop.

Taken with the transfer-at-spawn delivery point, D5, D6 and D8 are
unblocked. D7 remains blocked on question 8, and is not needed for either
ceiling.

docs/bounds-track-plan.md

@@ -111,13 +111,22 @@ Delegation is delivered in `onHello`. That works for a driver that says hello, a
    lands, where `hello` guarantees it cannot because the child is the one asking. That
    trade is the actual decision.
 
-7. **`virtio-gpu` hellos, but best-effort by design.** Its call is
-   `_ = device_manager.hello(.device, device_id);` with the comment "Best-effort:
-   standalone bring-up has no manager." Delegation would make the hello *mandatory* and
-   move it to the front, so the driver could no longer come up without a manager. No
-   test exercises standalone today (the `virtio-gpu` case boots the manager stack, and
-   devices.csv matches it), so this is a documented intent rather than a live path —
-   but discarding a documented intent is a decision, not a mechanical step.
+7. **`virtio-gpu`'s "standalone bring-up" — resolved; there is no such path.** An
+   earlier version of this question read the comment "Best-effort: standalone bring-up
+   has no manager" as a boot path that delegation would delete. It is not one.
+   `virtio-gpu`'s `main` requires `argv[1]` and exits without it, and the only source of
+   that argument is the device manager — the chain is ACPI → pci-bus reports the
+   function → `devices.csv` matches `1AF4:1050` → the manager spawns the driver with the
+   id. There is no way to run it without a manager, so nothing is lost.
+
+   What the comment is really about is **resilience**: the hello is best-effort so a
+   driver whose manager has *died* keeps serving, which device-manager.md states
+   ("If the manager dies, drivers keep running").
+
+   The residual is one narrow window: the manager spawns a driver and dies before
+   transferring. Today the driver could still claim, because claiming is free-for-all;
+   after D6 it exits and the restarted manager respawns it. That is the better
+   behaviour — a driver holding hardware nobody assigned it is what D6 exists to stop.
 
 Until these are answered, `device_claim` cannot be closed off at D6 for those three, so
 **D6 is blocked on questions 6 and 7**.