Docs: close the M21 track (events + system power)

docs/m19-m20-plan.md's M21 preview now points at the completed plan.

docs/m19-m20-plan.md

@@ -189,24 +189,8 @@ 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)
+## M21 — ACPI events + system power — DONE
 
-The acpi service grows the event side (settled direction 2026-07-13; detailed
+Built and merged (docs/m21-plan.md, 2026-07-13): the SCI + power button, Notify/GPE
-phases when M20 lands):
+dispatch, and orderly shutdown (init's stop cascade into a ring-3 S5 write).
-
+See that plan for the phase record.
-- **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.)