fix(usb): the xHCI controller is found by class on any bus, sized, taken from the firmware, and 64-byte contexts laid out

boards/BRINGUP.md A1, FABRIC-3 SXL.  It was matched by QEMU's own IDs on
bus 0 alone, so no real board's was found.  Now pci_find_class() reads
every bus/slot/function; pci_bar_size() sizes BAR0; the USB Legacy Support
capability hands the controller over from the BIOS, SMIs off; CSZ=1
contexts are placed 64 bytes apart instead of refused.  XHCI_QEMU_ARGS
lets QEMU place the controller as real hardware does.

Test first: an NEC controller behind a PCIe root port -- no attach before,
Zuse minted after, on all three ISAs.  Standard acceptance unchanged; five
hot-plugged identities attach.  Not rehearsable: firmware handoff, CSZ=1.
Still open: only the first controller found is used.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/fabric/FABRIC-3.md

@@ -5736,3 +5736,37 @@ needs ACPI; the Pi 5's is R4). The board image (`make boot_image TARGET=RASPI`)
 and ends at 0x834000. Standard acceptance, all three ISAs: POST 1052 passed, same hash
 (`logs/20261014-125305`, `-125427`, `-125635`).
 
+## XL. The USB controller found as real hardware has it (`boards/BRINGUP.md` A1, 2026-10-14)
+
+Captain Bob, 2026-10-14: "start on A1". The xHCI driver matched QEMU's own controller only --
+vendor and device `1B36:000D`, on PCI bus 0, function 0 -- so no real board's controller was ever
+found, and with it no thumbdrive, no login, no keyboard to come.
+
+**What a real controller needs, done:**
+- **Found by class**, `0x0C/0x03/0x30`, from any vendor: new `pci_find_class()` (`pci.c`) reads
+  every bus, slot and function the configuration space reaches (port I/O on amd64, all 256 buses;
+  through ECAM, the MCFG entry's bus range, now recorded). Real controllers sit behind bridges.
+- **Mapped at its real size**: new `pci_bar_size()` (the standard all-ones probe, decoding off
+  meanwhile); never less than the old fixed 64 KiB.
+- **Taken from the firmware** (xHCI 1.2 section 4.22.1): through the USB Legacy Support extended
+  capability, OS-owned set and BIOS-owned waited out for a second (taken regardless after, as
+  Linux does), every SMI enable off and SMI status cleared. QEMU's controller has no such
+  capability; a PC's BIOS, driving USB for its own setup screen, does.
+- **64-byte contexts** (`HCCPARAMS1.CSZ=1`) laid out, not refused: every context is 32 or 64 bytes
+  apart (`xhci_ctx_bytes()`); a 64-byte context holds the same fields in its first 32 bytes, so the
+  existing structs stand.
+- `XHCI_QEMU_ARGS` (`kernel/Makefile`) replaces the QEMU controller, to rehearse one placed as real
+  hardware places it.
+
+**Verified.** Test first: QEMU's NEC controller (`nec-usb-xhci`, vendor 1033) behind a PCIe root
+port on bus 1, Zuse's drive on it -- before, nothing attached and no `zuse@Hera` prompt
+(`logs/20261014-131238`); after, the drive attaches and Zuse is minted, on amd64 (`-131934`),
+aarch64 (`-132056`) and riscv64 (`-132257`). Standard acceptance with the usual controller, all
+three: POST 1052 passed, hash `0x82f4ae7cb2e2d424` unchanged (`-132431`, `-132548`, `-132746`);
+five identities hot-plugged, all attached (`-132912`).
+
+**Not rehearsable, so unproven until the SER5:** the firmware handoff and 64-byte contexts --
+QEMU's controller has neither. **Still open:** one controller only -- the first found. A PC with
+several (the SER5 has more than one) drives that one's ports alone; the stick and keyboard must be
+in them until the driver runs several (`xhci_get_dev()` is a single controller throughout).
+