Artemis Milestone 2b complete: xHCI PCI discovery and BAR0 mapping

New src/starkernel/usb/ subsystem directory (added to both
LOADER_SRCS_BASE and KERNEL_SRCS_BASE wildcards in Makefile.starkernel,
matching the existing virtio/*.c pattern). xhci_find_and_map() locates
the controller via the already-generic pci_find_first(), enables it,
maps BAR0 via the already-generic pci_map_bar(), and fills in all four
register-region pointers (cap/op/runtime/doorbell) plus max_slots/
max_ports/max_intrs from HCSPARAMS1 -- ready for controller bring-up
(2c) to consume directly.

No pci.c extension needed, per 2a's finding that PCI discovery here is
ID-based lookup (already generic), not class-code scanning. Verified:
clean standalone syntax check, full amd64 kernel build with zero
warnings, live boot still reaches POST 1012/0/0 unaffected (nothing
calls xhci_find_and_map() yet, so this is purely additive).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC-2.md

@@ -3093,16 +3093,28 @@ match" not "class code match"), and `pci_bar()`/`pci_map_bar()`/`pci_enable()` a
 generic, reusable as-is for the xHCI BAR0 mapping and bus-master enable. 2b is smaller than
 originally scoped.
 
-**2b. PCI discovery**
-- [ ] Extend `src/starkernel/pci/pci.c`'s enumeration to recognize the xHCI PCI class code
-      (Serial Bus Controller / USB Controller / xHCI programming interface) the same way it
-      already recognizes whatever device classes it currently handles (need to read
-      `pci.c`'s current class-match logic before extending it, not written from scratch)
-- [ ] Read and store the xHCI controller's BAR (memory-mapped I/O base address) from PCI
-      config space
-- [ ] Map that MMIO region into kernel virtual address space (via `vmm.c`'s existing
-      page-table machinery — confirm the right mapping-request function to call, matching
-      how virtio-blk's MMIO region gets mapped today as the closest existing precedent)
+**2b. PCI discovery ✅ DONE 2026-08-22**
+- [x] No `pci.c` extension needed after all (per 2a's bonus finding — `pci_find_first()` is
+      already generic ID-based lookup). New files instead: `include/starkernel/xhci_driver.h`
+      (driver state struct `xhci_dev_t` + public API) and `src/starkernel/usb/xhci.c`
+      (`xhci_find_and_map()`) — new `usb/` subsystem directory, added to both
+      `LOADER_SRCS_BASE` and `KERNEL_SRCS_BASE` wildcards in `Makefile.starkernel`, matching
+      the existing `virtio/*.c` wildcard pattern exactly.
+- [x] BAR0 read via the existing `pci_bar()` — no new code needed, direct reuse.
+- [x] BAR0 mapped via the existing `pci_map_bar()` — no new code needed, direct reuse. Mapping
+      size is a documented, explicit fixed assumption (`XHCI_BAR0_MAP_SIZE`, 64 KiB) rather
+      than real PCI BAR-size probing, since xHCI has no self-describing capability-region
+      length the way virtio PCI capabilities do (that mechanism was `virtio_blk.c`'s approach,
+      not available here) — flagged in a comment as a revisit point if it proves insufficient,
+      not swept under the rug.
+
+`xhci_find_and_map()` fills in all four register-region pointers (`cap`/`op`/`runtime`/
+`doorbell`) plus `max_slots`/`max_ports`/`max_intrs` from `HCSPARAMS1`, ready for 2c's
+controller bring-up to consume directly. Verified: standalone syntax check clean (`gcc -Wall
+-Wextra -fsyntax-only`), full amd64 kernel build succeeds with zero warnings (both loader and
+kernel compilation passes), and a live amd64 boot still reaches POST 1012/0/0 and `ok>`
+unaffected (expected — nothing calls `xhci_find_and_map()` yet, so this is purely additive
+until 2c wires it in).
 
 **2c. Controller bring-up**
 - [ ] Read Capability Registers to learn controller parameters (max device slots, max ports,