docs: the acpi service is discovery, not a driver awaiting an assignment

Question 6 lumped the acpi service in with ps2-bus as "a claimant that does
not hello". That was wrong about what it is. The manager starts it as
addDriver("discovery", no_device, false): the discovery service, one per
firmware, with no device assignment at all, which finds and claims the
acpi-tables node itself because it is the thing that produces the device
tree. The manager cannot hand it a device — at that point there is nothing
to match against.

So its question is not whether it should hello. It is whether the bootstrap
is exempt from D6, or whether the manager claims the acpi-tables node and
passes it on.

Recorded alongside it: a delivery point that needs no hello is already
implied by the code, since spawnSupervised returns the child's pid and the
manager could transfer immediately after spawn. If that is acceptable,
question 6 largely dissolves — ps2-bus would not need to leave "legacy"
either. The cost is ordering: the child may reach for the device before the
transfer lands, where hello guarantees it cannot because the child is the
one asking. That trade is the real decision, and it is now written down as
such.

docs/bounds-track-plan.md

@@ -89,15 +89,27 @@ They land together, with the manager claiming only for drivers in an explicit
 Delegation is delivered in `onHello`. That works for a driver that says hello, and
 **two of the four do not**.
 
-6. **`ps2-bus` and the `acpi` service never hello at all**, and that is deliberate:
-   device-manager.md records "Legacy drivers (e.g. ps2-bus) are supervised and
-   restarted but **not yet required to hello**", and the `Driver.speaks_protocol` flag
-   exists to say so. Delegating to them means either making them speak the protocol —
-   promoting them out of "legacy", which is a change to their documented status — or
-   giving the grant a second delivery point that is not `hello`. Neither is written
-   down. A second delivery point would also need its own answer to "when", since the
-   whole value of `hello` here is that it is the moment the driver is known to be alive
-   and is a synchronous point to hand something over.
+6. **`ps2-bus` does not hello**, and that is deliberate: device-manager.md records
+   "Legacy drivers (e.g. ps2-bus) are supervised and restarted but **not yet required
+   to hello**", and `Driver.speaks_protocol` exists to say so. Either it leaves
+   "legacy", or the grant gets a delivery point that is not `hello`.
+
+   **The `acpi` service is not this case — an earlier version of this question wrongly
+   lumped it in.** It is spawned as `addDriver("discovery", no_device, false)`: the
+   *discovery service*, one per firmware, with **no device assignment at all**, which
+   "finds and claims the acpi-tables (or devicetree-blob) node itself. Not a per-device
+   driver." The manager cannot hand it a device because discovery is what produces the
+   device tree — there is nothing to match against yet. Its question is not "should it
+   hello" but "is the bootstrap exempt from D6, or does the manager claim the
+   acpi-tables node and pass it on".
+
+   **A delivery point that needs no hello already exists in the shape of the code**:
+   `process.spawnSupervised` returns the child's pid, so the manager could transfer
+   immediately after spawn. If that is acceptable, this question mostly dissolves —
+   `ps2-bus` would not need to leave "legacy" and discovery could be handed its node
+   too. The cost is ordering: the child may reach for the device before the transfer
+   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: