Two APIC trees: x2APIC never enabled, boot wires the weaker LAPIC path

[eKisNonos]

There are two parallel, non-identical APIC stacks, and boot wires the weaker one for the LAPIC. sys/apic/* (detect-only x2APIC, primary IOAPIC only, no MSI-X) drives the live LAPIC/keyboard/mouse/timer; arch/x86_64/interrupt/* (enables x2APIC, up to 8 IOAPICs, real MSI-X) is used only by the broker and SMP.

Consequence: sys/apic/local/x2apic.rs:43 only latches the firmware x2 bit and never enables x2APIC, and the arch LAPIC init that would enable it (apic/init.rs:40) is never called on the BSP. adopt_bsp_state just copies whatever mode sys/apic left, which is never x2. So on real HW the LAPIC runs xAPIC even where x2APIC is supported, capping the machine at 255 CPUs and 8-bit APIC IDs (several ID reads use >>24 8-bit).

Widening: collapse the two trees into one LAPIC init (that enables x2APIC when CPUID says so) and one IOAPIC init (that walks all MADT IOAPICs). Also missing: IMCR handling for older PIC/APIC-switch chipsets, and applying the parsed MADT LAPIC-NMI entries to the live LINT pins. Interrupt remapping (VT-d IR) is absent, which IR-enabled firmware and >255-CPU x2APIC destinations will need.

[eKisNonos]

Confirmed, and worth stating precisely because it explains three other issues. Boot calls apic::init at src/boot/main/core_init/init_core_systems.rs:57, and the import on line 17 resolves that to the sys tree. src/sys/apic/local/x2apic.rs:43 only detects a firmware handoff: it records whether the enable bit is already set and writes the global enable bit alone. The tree that actually enables x2APIC is src/arch/x86_64/interrupt/apic/init.rs:40, and nothing calls it at boot; it only adopts what sys already did, at apic/adopt.rs:33. The TSC deadline timer, the HPET calibration and the RTC heartbeat in issue #420 all live in that same unreached tree, so they are one fix and not four.