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/danos-file-system-hierarchy-FSH.md

@@ -64,14 +64,15 @@ already provide — it claims its device, maps its registers with `mmio_map`, an
 on `replyWait` for either an interrupt or a client request. `system/drivers/hpet/hpet.zig` is already
 that program, minus the client half.
 
-The obstacle is not the file type, it is which hardware a ring-3 driver can actually
-drive. Port I/O is unavailable to user space — the TSS I/O permission bitmap is absent
-and IOPL is never raised — so `in`/`out` from a driver is a #GP. That excludes the
-16550 UART at `0x3F8` and PS/2 at `0x60`/`0x64`, which is to say it excludes the
-obvious implementations of `/dev/tty`, `/dev/ttyS0` and a keyboard node. Until either
-port I/O grants or a memory-mapped UART exist, serial output stays a kernel service
-reached through the `write` system call rather than a file. A memory-mapped device such
-as the framebuffer has no such problem and is the more likely first real entry here.
+The obstacle was never the file type; it is which hardware a ring-3 driver can reach.
+Direct `in`/`out` from user space is still a #GP (no TSS I/O bitmap, IOPL never raised),
+but a driver no longer needs it: **`io_read`/`io_write`** grant port access the same way
+`mmio_map` grants memory — gated by `device_claim` and the device's discovered `io_port`
+resource. So the 16550 UART at `0x3F8` and the PS/2 controller at `0x60`/`0x64` (and thus
+`/dev/ttyS0` and a keyboard node) are now writable as ordinary ring-3 drivers; the
+low-rate legacy hardware that needs port I/O is fine with a syscall per access. A
+memory-mapped device such as the framebuffer, needing no port I/O at all, remains the
+easiest first entry.
 
 ### Block devices
 
@@ -79,20 +80,23 @@ A block device is addressed in fixed-size blocks and, unlike a character device,
 layer above is free to buffer, reorder, coalesce and retry requests against it. Disks
 and other persistent storage are the whole population of this class.
 
-**danos cannot host a block driver at all today,** and the reason is worth stating
-plainly because it is not a matter of unwritten code. Every storage controller worth
-naming is a bus master: it is programmed by handing it the physical address of a
-descriptor ring and left to read and write memory on its own. A ring-3 driver cannot
-build such a ring, because `mmap` returns writeback-cached, physically discontiguous
-pages and never discloses their physical address. Nor should it be allowed to: a device
-programmed with an arbitrary physical address writes to arbitrary physical memory, and
-page tables do not sit between a device and RAM — an IOMMU does. Granting a DMA-capable
-device to a driver process, with no IOMMU programmed, is equivalent to granting ring 0,
-which would forfeit the isolation that motivates user-space drivers in the first place.
+A block driver is now **writable, but not yet memory-safe.** Every storage controller
+worth naming is a bus master: it is programmed by handing it the physical address of a
+descriptor ring and left to read and write memory on its own. That ring is exactly what
+**`dma_alloc`** now provides — physically contiguous, pinned, uncacheable, with its
+physical address disclosed — and **`/lib/mmio`**'s barriers order the descriptor writes
+against the doorbell, and **`msi_bind`** delivers completions. So an AHCI or NVMe driver
+can be written today (the M14/M15 work in [driver-model.md](driver-model.md); the earlier
+"cannot host a block driver at all" is no longer true).
 
-Block devices therefore wait on DMA-capable memory, memory barriers, and VT-d/DMAR —
-the M14–M16 work in [driver-model.md](driver-model.md). A ramdisk over the initial ramdisk is
-the one block-shaped thing implementable now, and it needs no driver process.
+What is *not* yet true is that it is safe. A device programmed with an arbitrary physical
+address writes to arbitrary physical memory, and page tables do not sit between a device
+and RAM — an IOMMU does. The IOMMU is now *detected* (M16), but no translation domains
+are programmed, so granting a DMA-capable device to a driver process is still equivalent
+to granting ring 0. Until per-device domains confine a driver's DMA to the buffers it
+`dma_alloc`'d, a block driver works but forfeits the isolation that motivates user-space
+drivers — enforcement is the next step, and lands with that first driver. A ramdisk over
+the initial ramdisk remains the one block-shaped thing that needs no driver process at all.
 
 ### Pseudo-devices