Discovery-migration prerequisites (M19.0)

The host bridge now carries MMIO apertures derived from the boot memory
map's gaps below 4 GiB (largest three, sort-merged; a single after-the-
last-region hole dies on OVMF's flash at the top) plus one aperture above
the described space — so a user-space device_register of PCI functions
with BAR resources can pass containment. The discovery test asserts
every PCI memory resource lies inside a bridge window and names any
escapee. device_register is idempotent on exact (parent, class, identity,
resources) match — a restarted registering bus cannot duplicate its
children; proven directly against the broker in the bus test.
ChildAdded gains device_id so a report can carry the registered kernel
id a matched driver needs as its assignment.

docs/m17-m18-plan.md

@@ -1,5 +1,9 @@
 # M17–M18 execution plan: process lifecycle + device manager
 
+**Archived — completed 2026-07-13** (every item checked; suite ended 54/54).
+Kept as the record of how M17–M18 landed; the successor is
+[m19-m20-plan.md](m19-m20-plan.md).
+
 The operational plan for building [process-lifecycle.md](process-lifecycle.md)
 (M17) and [device-manager.md](device-manager.md) increments 5–7 (M18). Design is
 settled in those documents; this file is the build order — one phase at a time,

docs/m19-m20-plan.md

@@ -79,9 +79,11 @@ branch is green; keep branches; push everything.
 
 ## Status
 
-- [ ] **M19.0** — prerequisites on `feat/pci-bus`: bridge MMIO apertures from
-      the memory-map holes; `device_register` idempotence (+ kernel unit
-      checks); `ChildAdded.device_id`; archive note on m17-m18-plan.md.
+- [x] **M19.0** — prerequisites (bridge apertures from the memory map's
+      *gaps* — the single-hole rule died on OVMF's flash at the top of 4 GiB,
+      caught by the new every-BAR-contained assert in `discovery`; idempotent
+      `device_register` proven in `bus`; `ChildAdded.device_id`;
+      m17-m18-plan.md archived; suite 54/54).
 - [ ] **M19.1** — pci-bus driver, scan only: claim the host bridge, map the
       ECAM window, walk bus/device/function headers, log what it finds.
       Scenario `pci-scan`: the kernel test compares the driver's reported count