The PCI scan from ring 3: pci-bus walks the ECAM it mapped (M19.1)

The manager matches the pci_host_bridge node and spawns pci-bus with the
bridge id as its assignment — hello, supervision, restart, all the M18
contract for free. The driver claims the bridge, maps the ECAM window
(resource 0) through the ordinary mmio grant, and repeats the kernel's
brute-force bus/device/function walk from user space. The pci-scan
scenario builds its expected marker from the kernel's own function count,
so the two enumerations must agree exactly — the equivalence that
licenses retiring the kernel walk in M19.3.

docs/m19-m20-plan.md

@@ -84,10 +84,11 @@ branch is green; keep branches; push everything.
       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
-      against the broker table's `pci_device` count — equivalence, per class.
+- [x] **M19.1** — pci-bus driver, scan only (claims the bridge, maps ECAM
+      through its grant, brute-force walk with the multifunction rule; the
+      manager matches pci_host_bridge → pci-bus per device with the full
+      protocol contract; `pci-scan` builds its expected marker from the
+      kernel's own count — equivalence on the first run; suite 55/55).
 - [ ] **M19.2** — register + report: each function registered under the bridge
       (config-space slice + BARs, `pci_class` in the descriptor), reported with
       `child_added { device_id, identity = class triple }`. Manager mirrors;