The acpi service evaluates _CRS/_STA in ring 3 and reports devices (M20.2)

AML method evaluation now runs in userspace touching real hardware: the
service builds an interpreter with a ring-3 Hal (port I/O routed through
its claimed acpi-tables node; a scratch page backs SystemMemory maps so a
stray OperationRegion degrades to zeros instead of faulting a process
that cannot map arbitrary physical memory). It walks the namespace and,
for each present _HID device that is not a PCI root, evaluates _CRS,
registers it under acpi-tables, and reports it with its EISA-decoded hid.

Containment for this needed the broker's irq check to become range-based
— an interrupt line is still indivisible, but a parent may own a range,
so the acpi-tables node's broad irq window contains its children's legacy
lines (a length-1 range is exactly the old equality, so single-irq
parents are unaffected). ChildAdded gained a hid field for firmware
string identity. Matching those reports to drivers stays off until M20.3,
so ps2-bus still comes up via the kernel path — no regression. The
acpi-report scenario proves the PS/2 keyboard (io 0x60/0x64 + IRQ) and
mouse (IRQ) are reported with their resources. Suite 57/57.

system/services/device-manager/device-manager.zig

@@ -151,7 +151,7 @@ const Child = struct {
     reporter: u32 = 0, // the reporting driver instance's process id
 };
 
-const maximum_children = 32;
+const maximum_children = 64; // ACPI adds ~34 device nodes (M20.2), plus PCI + USB
 var children: [maximum_children]Child = .{Child{}} ** maximum_children;
 
 /// Record (or refresh) a reported child. Refreshing matters: a restarted bus