FABRIC-2.md Section X: fix Milestone 2's sub-item labels 3a-3h -> 2a-2h

Leftover from the milestone renumbering -- cross-references elsewhere
already said "Milestone 2e" etc., but the bare sub-item labels inside
Milestone 2's own section still said "3a."-"3h.". Now consistent.

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

FABRIC-2.md

@@ -3067,7 +3067,7 @@ Nothing in Section U/V/W's home-blocks thread is testable past this point withou
 roughly bottom-up: PCI discovery → controller bring-up → command/event rings → port/hotplug
 detection → device enumeration → mass-storage class → read/write.
 
-**3a. Research/spec groundwork (do first, nothing below can be scoped precisely without it)**
+**2a. Research/spec groundwork (do first, nothing below can be scoped precisely without it)**
 - [ ] Confirm xHCI is the right target controller class (vs. EHCI/OHCI) for QEMU's
       `qemu-xhci` device and for realistic modern real hardware — xHCI is the USB 3.x
       standard and QEMU's default modern USB controller, but confirm no fallback to EHCI is
@@ -3080,7 +3080,7 @@ detection → device enumeration → mass-storage class → read/write.
 - [ ] Decide command-ring and event-ring sizes/allocation strategy up front (fixed small
       ring vs. dynamically sized) — affects the memory-management code below
 
-**3b. PCI discovery**
+**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
@@ -3091,7 +3091,7 @@ detection → device enumeration → mass-storage class → read/write.
       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)
 
-**3c. Controller bring-up**
+**2c. Controller bring-up**
 - [ ] Read Capability Registers to learn controller parameters (max device slots, max ports,
       max interrupters — needed to size later allocations)
 - [ ] Perform xHCI controller reset sequence
@@ -3103,7 +3103,7 @@ detection → device enumeration → mass-storage class → read/write.
 - [ ] Set the `RUN/STOP` bit to start the controller
 - [ ] Confirm controller reaches a running state (poll a status register, don't assume)
 
-**3d. Interrupt/event handling**
+**2d. Interrupt/event handling**
 - [ ] Wire an interrupt handler for the xHCI controller's IRQ line (via existing per-arch
       interrupt infrastructure, `starkernel/arch/*/interrupts.c` — same place the timer ISR
       already hooks in, per the heartbeat work this session)
@@ -3112,7 +3112,7 @@ detection → device enumeration → mass-storage class → read/write.
 - [ ] Implement Event Ring dequeue-pointer update / interrupt-clear sequence so the
       controller keeps delivering new events
 
-**3e. Hotplug detection (the actual trigger for everything in Section U)**
+**2e. Hotplug detection (the actual trigger for everything in Section U)**
 - [ ] On a Port Status Change event, read the corresponding Port Register to determine
       connect vs. disconnect
 - [ ] On connect: allocate a Device Slot (Enable Slot command via the Command Ring), address
@@ -3125,7 +3125,7 @@ detection → device enumeration → mass-storage class → read/write.
       calling into block_subsystem.c directly (matching the existing "kernel/Artemis
       decoupling boundary" pattern already documented in `block_subsystem.c`)
 
-**3f. USB device enumeration (post-connect, before it's usable as storage)**
+**2f. USB device enumeration (post-connect, before it's usable as storage)**
 - [ ] Request and parse the device descriptor (confirm vendor/product IDs are even needed,
       or if class-only detection suffices for this project's purposes)
 - [ ] Request and parse the configuration descriptor
@@ -3135,7 +3135,7 @@ detection → device enumeration → mass-storage class → read/write.
       layer up, after the drive is already known to be USB mass storage)
 - [ ] Set the device configuration (SET_CONFIGURATION control transfer)
 
-**3g. Bulk-Only Transport (BOT) — the actual read/write path**
+**2g. Bulk-Only Transport (BOT) — the actual read/write path**
 - [ ] Identify and configure the device's bulk IN and bulk OUT endpoints
 - [ ] Implement CBW (Command Block Wrapper) construction and send, for a SCSI READ(10)
 - [ ] Implement CSW (Command Status Wrapper) receive and status check
@@ -3146,7 +3146,7 @@ detection → device enumeration → mass-storage class → read/write.
 - [ ] Implement basic error/stall recovery (CSW failure status, endpoint stall clear) — at
       minimum enough to not wedge the controller on a single bad transfer
 
-**3h. Integration with the existing block subsystem**
+**2h. Integration with the existing block subsystem**
 - [ ] Wire a working USB MSC device into `blk_subsys_attach_device()` (or
       `blk_subsys_add_raw_device()`, whichever fits — confirm which, since USB is
       persistent+removable, a hybrid of the two existing categories) — this is the point