Bring the docs up to the M17-M18 reality; pre-settle M19-M20 ambiguities

resilience.md: steps 1-4 of the ladder are built — supervision, exit
reasons, restart with backoff, crash-loop caps, all proven by scenario;
what remains is scope, not mechanism. README statuses follow. drivers.md
gains the driver-contract section (harness, hello, crash-freely). The
M19-M20 plan pre-settles three things the loop would otherwise have had
to decide alone: the memory-map pass-through for apertures, the manager
spawning 'discovery' from M20.1, and hid[8] riding ChildAdded for ACPI
string identity until the FDT widening.

docs/m19-m20-plan.md

@@ -122,7 +122,9 @@ branch is green; keep branches; push everything.
 ## Phase notes
 
 **M19.0 apertures:** the boot memory map already crosses the handoff
-([boot-handoff]); the holes computation belongs where the bridge node is built
+([boot-handoff]), but discovery never sees it today — expect a small
+pass-through (kernel init hands the map to the platform layer) before the
+holes computation, which belongs where the bridge node is built
 (`parseMcfg`). Sanity-check on QEMU q35: the xHCI BAR (`0xc0000000`-region
 values seen in the M18 logs) must land inside a derived aperture, asserted in
 the kernel unit test.
@@ -142,6 +144,13 @@ scenario can assert it.
 kernel still enumerates (timers, ACPI nodes until M20.3). The PCI arm of
 `pciDriverFor` switches source; `driverFor` doesn't move until M20.3.
 
+**M20.1 spawn and identity (pre-settled 2026-07-13):** the manager spawns
+`discovery` by its neutral ramdisk name at startup, as an ordinary protocol
+driver (hello, supervision) — from M20.1 on, on every boot. For reporting ACPI
+devices, `ChildAdded` gains `hid: [8]u8` (EISA ids fit; zero = none):
+firmware *string* identity travels beside the numeric `identity` field until
+the FDT-driven widening replaces both (decision 7).
+
 **M20.1 Hal in ring 3:** `mapMmio` → `device.mmioMap` over the claimed
 acpi-tables node (plus a table-offset map for blobs); `pioRead`/`pioWrite` →
 `device.ioRead`/`ioWrite` against its io_port resource. The interpreter cannot