Port I/O grants (io_read / io_write) + refresh stale driver docs

Ring 3 still has no direct in/out (no TSS I/O bitmap, IOPL never raised — a #GP), but a
driver no longer needs it: io_read(device_id, resource_index, offset, width) and
io_write(..., value) grant port access the same way mmio_map grants memory. The claim
plus the device's discovered io_port resource are the capability — resolveIoPort checks
the device is claimed by the caller, the resource is io_port, and [offset, offset+width)
stays inside it, then issues the in/out via architecture.pioRead/pioWrite. So a PS/2 or
16550 driver is now writable; the low-rate legacy hardware that needs port I/O is fine
with a syscall per access. io_port resources were recorded by discovery and ignored —
now they're used. Runtime: device.ioRead/ioWrite.

New `ioport` test claims QEMU's PS/2 controller (io_port 0x64, discovered via ACPI) and
checks the gate admits an in-range access, refuses over-wide / out-of-range / unclaimed,
and that the kernel actually reads the status port (0x1c). Suite 41/41 plus host tests.

Docs refreshed for the whole M13-M16 + port-I/O reality: drivers.md "Limits" no longer
lists port I/O, DMA memory, or barriers as missing (they exist) and its "what's next"
reflects that; the FSH doc's character-device and block-device sections are corrected
("cannot host a block driver at all" is no longer true — writable now, not yet memory-
safe pending IOMMU enforcement); device-interrupts.md unblocks the keyboard and narrows
the interrupt gap to MSI-X.

docs/drivers.md

@@ -266,26 +266,24 @@ controller drivers fit together.
 
 Worth knowing before you write the second driver:
 
-- **Ring 3 has no port I/O.** The TSS I/O permission bitmap is absent
-  (`tss.zig`: `iomap_base = @sizeOf(Tss)`), and IOPL is never raised, so `in`/`out`
-  from a driver is a #GP. That rules out a user-space 16550 UART (`0x3F8`), PS/2
-  (`0x60`/`0x64`), and legacy PCI config (`0xCF8`/`0xCFC`). Everything must be MMIO.
-  `io_port` resources are recorded by discovery and then ignored.
+Several things this list used to warn about are now available (see
+[driver-model.md](driver-model.md)): **port I/O** (`io_read`/`io_write`, claim-gated by
+the device's `io_port` resource — direct ring-3 `in`/`out` is still a #GP, so a PS/2 or
+16550 driver goes through these), **DMA memory** (`dma_alloc`: contiguous, pinned,
+uncacheable, physical address exposed), and **memory barriers** (`/lib/mmio`'s
+`mb`/`rmb`/`wmb`). What remains:
+
 - **Page granularity.** `mmio_map` rounds to 4 KiB. Two devices sharing a page means
   granting one grants the other. A `device_register`ed child's *resource* can be narrower
   than a page, but its *mapping* can't.
-- **No DMA memory.** `mmap` gives you writeback-cached, non-contiguous pages and never
-  tells you their physical address, so you cannot build a descriptor ring. Any driver
-  for a bus-mastering device is blocked on this.
-- **No memory barriers.** There are none in the tree, and `volatile` is not one — it
-  won't stop the compiler sinking an ordinary store (your DMA descriptor) past a
-  volatile MMIO store (your doorbell). On x86 you mostly get away with it; on ARM you
-  will not. See [driver-model.md](driver-model.md#m14).
 - **DMA is not contained.** A driver that can program a bus-mastering device can make
   that device write to *any* physical address — page tables don't sit between a device
-  and RAM; an IOMMU does. Until VT-d/DMAR is programmed, `device_claim` on a DMA-capable
-  device is effectively equivalent to granting ring 0. This is the largest gap between
-  the design's promise and what it delivers.
+  and RAM; an IOMMU does. The IOMMU is now *detected* (M16), but no translation domains
+  are programmed, so `device_claim` on a DMA-capable device is still effectively
+  equivalent to granting ring 0. This is the largest gap between the design's promise and
+  what it delivers; enforcement lands with the first DMA driver.
+- **No `dev_release`.** A claim is never dropped (only IRQ/MSI bindings are, on exit), so
+  a device stays owned for the life of its driver — which blocks restart.
 - **One endpoint per GSI**, so shared legacy PCI INTx lines can't be split between two
   drivers. MSI/MSI-X — one vector per device, edge-triggered, unshared — is the real
   answer, and QEMU's HPET doesn't offer it (`Tn_FSB_INT_DEL_CAP = 0`).
@@ -341,14 +339,12 @@ Two companions cover what `hpet` can't, because it never exits:
 
 ## What's next (not done here)
 
-The big ones — capability passing (class drivers), DMA + barriers and MSI (host
-controller drivers), and the IOMMU — have proposed signatures in
-[driver-model.md](driver-model.md). Smaller items:
+The big driver-model pieces — capability passing (class drivers), DMA + barriers, MSI,
+and IOMMU detection — are **now done** ([driver-model.md](driver-model.md), M13–M16), as
+is **port I/O** (`io_read`/`io_write`, the claim-gated syscalls that make a PS/2 or 16550
+driver possible). What's left is IOMMU *enforcement* (per-device domains — it waits on
+the first DMA driver to protect and test against) and these smaller items:
 
-- **Port I/O grants**, so a PS/2 or 16550 driver is possible: either a per-device TSS
-  I/O permission bitmap swapped on context switch, or `io_in`/`io_out` syscalls gated
-  by the same claim. The legacy devices that need it are all low-rate, so the syscall
-  is likely fast enough.
 - **Releasing a claim.** There is no `dev_release`, and `devices_broker` never drops a claim on
   exit — only IRQ bindings are released. A dead driver's device stays owned forever,
   which blocks restart.