hybrid: H4 is not the same shape as the GPU, and say so

The milestone reads "USB, same shape", written before the GPU eviction had
actually been done. Two differences, both found by looking at what depends
on USB rather than at xhci.c.

The GPU could leave because there was a working fallback underneath it --
the VBE framebuffer stays in the kernel, which is one of the four reasons
it was chosen to go first. USB has no fallback and carries two things on
the path to a shell: the root disk, through bio.c's USBDISK_DEV dispatch
and the usbstick.img `make` builds, and the keyboard, through usb_hid into
input_report -- which is how anything without PS/2 is typed on, including
the Chromebox this is meant to boot. Evicting xhci.c wholesale produces
this plan's own circular boot failure with different clothes on: the root
filesystem cannot mount because the storage driver is a process that lives
on the root filesystem.

The subtler difference is probably the harder one. /dev/pci hands over a
PCI function -- one device, one owner, nothing shared. A USB device sits
behind a controller other devices also sit behind, so the unit of ownership
and the unit of hardware stop being the same thing. Handing a process "the
xHCI controller" hands it the keyboard too; handing it "one USB device" is
an interface /dev/pci does not have and this plan has not designed.

No code. H4 needs that interface decided first, and recording it here beats
discovering it halfway through 2,550 lines.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2

docs/plan/hybrid.md

@@ -407,6 +407,47 @@ Four reasons it is the right one and not just the interesting one:
 abstraction, and it is where third-party drivers will show up first. This is what
 DriverKit was built for and the resemblance is not accidental.
 
+#### It is not the same shape as the GPU, and that was missed
+
+Written before the GPU eviction had been done, H4 says *"USB, same shape"*. It
+is not, and the difference is one this document's own rule already decides.
+
+The GPU could leave because **there was a working fallback underneath it**: the
+VBE framebuffer stays in the kernel, so a GPU driver that fails to start
+degrades to a working screen. That is one of the four reasons the GPU was
+chosen to go first, listed a few lines above.
+
+USB has no fallback, and it carries two things that are on the path to a shell:
+
+- **The root disk.** `USBDISK_DEV` dispatches through `bio.c` to
+  `usb_storage_rw`, and `usbstick.img` is a real boot medium built by `make`.
+- **The keyboard.** `usb_hid` feeds `input_report(INPUT_KBD, ...)`, which is how
+  anything without PS/2 is typed on — including the Chromebox this is meant to
+  boot.
+
+So evicting `xhci.c` wholesale breaks the rule three sections down:
+
+> **The kernel keeps a minimal driver for everything on the path to a shell, and
+> userspace owns the good one.**
+>
+> Break this and you get the circular boot failure where the compositor cannot
+> start because the display driver is a process that needs a compositor.
+
+The USB version of that sentence is *the root filesystem cannot mount because
+the storage driver is a process that lives on the root filesystem*, and it is
+the same failure wearing different clothes.
+
+There is a second difference, subtler and probably the harder one. `/dev/pci`
+hands over a **PCI function** — one device, one owner, nothing shared. A USB
+device is not that: it sits behind a controller that other devices also sit
+behind, so the unit of ownership and the unit of hardware are no longer the
+same thing. Handing a process "the xHCI controller" gives it the keyboard too;
+handing it "one USB device" is an interface `/dev/pci` does not have and that
+this plan has not designed.
+
+**H4 needs that interface designed before it needs code.** Recorded here rather
+than discovered halfway through 2,550 lines.
+
 ### The rule that keeps the boot path honest
 
 > **The kernel keeps a minimal driver for everything on the path to a shell, and