usb: the controller says how many device slots it has

max_devices was 8, with the comment "QEMU presents a handful; a fuller
machine would grow this" — a number chosen against the test rig, waiting for
a real machine, which is the pattern docs/bounds-track-plan.md exists to
stop.

The driver already knew the true figure. It reads HCSPARAMS1.MaxSlots at
bring-up and writes it straight into op_config, so every slot the controller
offers has always been *enabled*; only the array tracking them was 8. QEMU's
xHCI reports 64, so seven eighths of the controller was live and invisible,
and the ninth device — a keyboard, mouse, webcam, headset, hub and two
sticks reach that without trying — disappeared on a hub-attached path that
logs nothing at all.

The array becomes a slice allocated from max_slots at bring-up. A controller
claiming zero slots cannot address anything, so that is now a dead
controller rather than an empty allocation failing mysteriously later. The
Device Context Base Address Array is a page, 511 usable entries, so it
already covered the 255-slot maximum.

The bring-up line reports both numbers, and usb-hid asserts they are equal
with a backreference rather than a magic number, so the test cannot drift
from the hardware. Pinning tracking back to 8 fails it: "64 slots,
tracking 8".

Suite 115/115.

tools/bounds-allowlist.txt

@@ -83,7 +83,6 @@ system/drivers/usb-xhci-bus/usb-xhci-library.zig:data
 system/drivers/usb-xhci-bus/usb-xhci-library.zig:descriptor
 system/drivers/usb-xhci-bus/usb-xhci-library.zig:head
 system/drivers/usb-xhci-bus/usb-xhci-library.zig:header
-system/drivers/usb-xhci-bus/usb-xhci-library.zig:max_devices
 system/drivers/usb-xhci-bus/usb-xhci-library.zig:max_endpoints_per_interface
 system/drivers/usb-xhci-bus/usb-xhci-library.zig:max_interfaces
 system/drivers/usb-xhci-bus/usb-xhci-library.zig:max_subscriptions