M16: IOMMU detection (DMAR parsing)

Detect the IOMMU: discovery now parses the ACPI DMAR table, finds the first VT-d
DMA-remapping unit (DRHD), maps its register block, and records its version and
capabilities (iommu_present/base/version/capabilities in the platform info). On QEMU's
emulated intel-iommu this reads back a real unit (base 0xfed90000, version 1.0).

This is detection only, and deliberately so. A full VT-d bring-up — per-device
translation domains that confine a driver's DMA to the buffers it dma_alloc'd — is the
real device-side safety guarantee, but it cannot be verified without a DMA-capable
device driver (none exist yet) and QEMU's intel-iommu to fault against. Writing that
enforcement now would be a large body of unverifiable page-table code; it belongs with
the first DMA driver, which is both the natural order and the only way to test it. Until
then the caveat stands in full: device_claim on a DMA-capable device is still equivalent
to granting ring 0. The docs say so plainly.

New `iommu` test (harness boots it with -device intel-iommu via a new per-case qemu_extra
hook) confirms the DMAR is parsed and the unit's registers read. Suite 40/40 plus host
tests.

docs/driver-model.md

@@ -152,6 +152,12 @@ If a class driver needs `mmio`, it has become an HCD and should be one.
   ack cycle. Legacy INTx (`_PRT` parsing + shared lines) is deliberately skipped — MSI
   is the real answer. QEMU's HPET has no MSI, so delivery is proven with a self-IPI; the
   first PCI driver is the first real consumer.
+- **M16 (detection)** — the IOMMU is now *found*: discovery parses the ACPI DMAR table,
+  maps the first VT-d unit, and reads its version + capabilities (`iommu_present` in the
+  platform info). This is detection only — **no translation domains are programmed, so
+  DMA is still unprotected** (the caveat below). Enforcement lands with the first DMA
+  driver, which is what there is to protect and test against. Proven in the `iommu` test,
+  booted with an emulated `intel-iommu`.
 - **`system_spawn`** — a user-space supervisor starts a driver: `system_spawn(name)`
   loads a binary bundled in the initial-ramdisk as a fresh ring-3 process. This is what
   turned the device manager from "log the match" into "run the driver": the kernel now
@@ -314,7 +320,14 @@ capability walk (MSI, MSI-X, PCIe extended caps) without any new syscall.
 Note QEMU's HPET reports `Tn_FSB_INT_DEL_CAP = 0` — no MSI — so `hpet` can never
 exercise this path. The first MSI driver will be the first PCI driver.
 
-## M16 — the IOMMU, and the honest caveat
+## M16 — the IOMMU, and the honest caveat  ◑ detection done, enforcement pending
+
+*The IOMMU is now detected (DMAR parsed, VT-d unit mapped and read — see the `iommu`
+test), but **enforcement is not built**: no translation domains are programmed, so the
+caveat below still holds in full. Detection can't be taken further usefully until there
+is a DMA driver to protect and QEMU's `intel-iommu` to test the protection against —
+building the per-device domains alongside that first driver is both the natural order
+and the only way to verify them. The rest of this section is the original caveat.*
 
 Everything above is capability-gated at the *CPU*. None of it is gated at the *device*.
 A driver that can program a bus-mastering engine can make that device write to any