Scope ACPI events and system power as M21; record the SCI on acpi-tables

Battery, AC, lid, and the power button ride the acpi service as reported
children with small class drivers — the xHCI split repeated. QEMU can
only prove the power-button path (system_powerdown injects the real fixed
event), so battery/EC are interface-complete and hardware-validated on
the laptop. Per-device power states (D-states, suspend/resume) stay out
of scope: suspend has the shape of a lifecycle signal every driver must
answer, and it has no consumer until laptop sleep.

docs/m19-m20-plan.md

@@ -80,9 +80,11 @@ branch is green; keep branches; push everything.
       the suite must not be able to tell the difference. discovery.md updated.
 - [ ] **merge** `feat/pci-bus` → main, push.
 - [ ] **M20.1** — acpi service, parse only: kernel publishes `acpi-tables`
-      (decision 5); the service claims it, maps the blobs, runs the shared AML
-      module in ring 3, logs the namespace device count and `_HID`s. Scenario
-      `acpi-parse`: user-space count equals the kernel walk's count.
+      (decision 5) — memory over the table blobs, the broad io_port grant, and
+      **the SCI as an irq resource** (from the FADT; unused until M21 but free
+      to record now). The service claims it, maps the blobs, runs the shared
+      AML module in ring 3, logs the namespace device count and `_HID`s.
+      Scenario `acpi-parse`: user-space count equals the kernel walk's count.
 - [ ] **M20.2** — register + report: namespace devices with `_HID` + `_CRS`
       resources registered under `acpi-tables` (its io_port + the memory-map
       holes give containment), reported to the manager. Spawn-from-reports for
@@ -135,6 +137,31 @@ its spawn moves behind the report (the manager's matching handles this once
 the source flips); the `input` scenario proves the keyboard still types.
 
 **Explicitly out of scope:** PCI bridge recursion (single segment, flat bus
-walk stays); BAR reprogramming/sizing; hotplug (PCIe native or ACPI);
-interrupt routing changes (`_PRT` stays wherever it is today); the USB
-descriptor track; multi-segment ECAM.
+walk stays); BAR reprogramming/sizing; disk/PCIe hotplug; interrupt routing
+changes (`_PRT` stays wherever it is today); the USB descriptor track;
+multi-segment ECAM; per-device power states (D-states, `_PSx`/`_PRx`,
+suspend/resume — a future *lifecycle-vocabulary* extension, since "suspend"
+has the shape of a signal every driver must answer, and it has no consumer
+until laptop sleep); CPU P/C-states.
+
+## M21 preview — ACPI events + system power (planned next, not in this loop)
+
+The acpi service grows the event side (settled direction 2026-07-13; detailed
+phases when M20 lands):
+
+- **21.1 SCI + fixed events**: irq_bind the SCI (the resource M20.1 already
+  records), read/clear PM1 status, publish the power-button event to
+  subscribers (the same pub/sub shape the manager uses).
+- **21.2 GPE + Notify**: Notify dispatch in the shared AML interpreter, GPE
+  block handling, `Notify(device, code)` published per reported node. The
+  acpi service is a **bus** here: battery (PNP0C0A), AC (ACPI0003), and lid
+  (PNP0C0D) nodes are reported children; small class drivers bind them and
+  speak an evaluate/subscribe protocol to the service — the xHCI split,
+  repeated. The embedded controller (`_Qxx` queries) rides this phase;
+  QEMU emulates no battery/EC, so those paths are interface-complete and
+  validated on real hardware (the laptop is the win condition), while the
+  plumbing is proven by the power button.
+- **21.3 the capstone**: QEMU `system_powerdown` → acpi service event → init
+  runs the M17 stop sequence over its children → kernel `\_S5` — orderly
+  shutdown as the scenario that proves lifecycle + events compose. (The
+  harness grows a QMP poke to inject the event.)