library: the last three protocols speak the envelope

These were the awkward ones. Each began with an operation packed into a
single byte — two of them with a version wedged in beside it — so there was
no wrapping them: the layouts had to be rebuilt. The device manager's own
enumerate and subscribe become the reserved verbs that mean the same thing
everywhere, its replies lose three status structs the envelope already
carries, and a device id becomes the packet's target. Power drops the
version it repeated on every request, because describe is the handshake,
and stops claiming a 64-byte ceiling it never needed for calls. USB moves a
control transfer's data to the packet tail in both directions, which makes
the status length the transferred length and retires a field that had been
saying the same thing twice.

The danger in this one was not the protocols but their readers. Init
recognised a power button by two bytes at the head of a message, the ACPI
service dispatched on the first byte, the xHCI driver read its operation
with a raw integer load, and the HID drivers reinterpreted a report
wholesale — none of which would have failed to compile once the layouts
moved. They would simply have stopped: no shutdown on the power button, no
reports from the keyboard. Every one of them now reads through the
generated types, and the shutdown gate that answers only a subscriber is
the same code it was.

Two sizes were decided by measuring rather than assuming. The child-added
message is both a request and the event broadcast to subscribers, and
alignment rounds it to 48 bytes, which puts its packet exactly on the
64-byte push floor — a test pins that, because a field added carelessly
would now overflow it. The interrupt report gives up eight bytes of inline
room to make space for the header; the two drivers that produce reports
send eight and four.

Suite 110/110.

docs/device-driver-development/device-manager.md

@@ -64,19 +64,38 @@ restarted instance to rebuild exactly the same ids.
 
 ## The protocol
 
-A `device-manager-protocol` module (the vfs-protocol pattern): extern-struct
-messages, a version in the handshake, reserved fields everywhere. The manager is a
-well-known endpoint (`ipc.register(.device_manager)`); the badge tells it who is
+A `device-manager-protocol` module, defined through the
+[envelope](../os-development/protocol-namespace.md): every packet — request,
+reply, and pushed event alike — begins with the folded `Header`, and **the device
+id is `Header.target`**, the manager's object addressing. The contract is bound at
+`/protocol/device-manager`; the kernel-stamped badge tells the manager who is
 talking; the same endpoint receives its children's exit notifications — one loop,
 one world.
 
-| Direction | Message | Purpose |
+| Direction | Packet | Purpose |
 |---|---|---|
-| driver → manager | `hello { version, role, device_id }` | confirms the argv assignment, starts the deadline clock |
-| bus → manager | `child_added { parent, bus_address, identity, device_id, hid }` | one node the bus discovered |
+| driver → manager | `hello { role, version }` @ the assigned device | confirms the argv assignment, starts the deadline clock |
+| bus → manager | `child_added { parent, bus_address, identity, bus, vendor, device, subsystem, hid }` @ the registered device id | one node the bus discovered |
 | bus → manager | `child_removed { parent, bus_address }` | unplug, or the bus lost it |
-| app → manager | `enumerate` | snapshot of the tree (read-only) |
-| app → manager | `subscribe` | receive published add/remove events |
+| app → manager | `enumerate` (reserved verb 1) | snapshot of the tree: one `ChildEntry` per record in the reply's tail |
+| app → manager | `subscribe` (reserved verb 2) | receive published add/remove events; the subscriber's endpoint rides as the call's capability |
+| manager → app | `child_added` / `child_removed` events | the same two structs, pushed rather than called |
+
+Two of what used to be the manager's own operations are the envelope's **reserved**
+verbs, which mean the same thing at every provider in the system, so this protocol
+numbers only three of its own (`hello` = 16, `child_added` = 17,
+`child_removed` = 18) and its two events in their own space (`child_added` = 16,
+`child_removed` = 17). No reply carries a status field: that is the `Status` every
+reply begins with.
+
+`child_added` is the one struct that travels both ways — a bus *calls* it, the
+manager *pushes* it — which is why the operation and event numbering spaces are
+separate: one encoding, both directions, told apart by which way the packet went.
+Folding the operation byte and the device id out of it is also what makes it fit:
+a pushed event is 64 bytes at most, header included, and this one lands exactly on
+that floor. `child_removed` is the single message whose target stays 0, because it
+is addressed by the composite (parent, bus address) and no single `u64` carries a
+pair.
 
 `hello` is the one deadline the manager enforces itself: spawned and silent past the
 deadline means wrong binary, wrong protocol version, or wedged before main — apply