aarch64: IRQ resume corrupts preemptible kernel-thread page-table construction

[ryanbreen]

Summary

A PostScheduler kernel thread can resume from an IRQ with an in-flight ProcessPageTable construction corrupted. This was isolated while validating #470; fixing the interrupt/context-switch path is out of scope for that PR and requires scrutiny of prohibited timing-sensitive files.

Evidence

• The Reclaim active process page-table hierarchy on exit #470 pairing oracle intermittently observed malformed L1/L2/L3 descriptors before the root entered PROCESS_MANAGER or the deferred-reclaim queue.
• Checkpoints localized corruption to ProcessPageTable::new/map_page in the synthetic PostScheduler builder.
• Active-frame tracking found no duplicate allocation, premature deallocation, free-list duplication, or table/leaf alias.
• Corrupt raw values such as 0x1d matched formatter/string-length values live in generated AArch64 code during the construction window.
• per_cpu_aarch64::preempt_disable did not eliminate the failure (failure by run 20). Masking local IRQs only around construction eliminated it in 50/50 consecutive full-device boots. The reclaim and scoring windows remained interruptible.

Reproduction

Run the #470 fork_exit_defer_reclaim_pairing_test synthetic page-table builder in a PostScheduler kthread without local IRQ masking, using the full five-device QEMU configuration. Same-build campaigns failed intermittently, including malformed roots immediately after ProcessPageTable::new and malformed intermediate tables immediately after map_page.

Constraints

Investigate with GDB/QEMU tracing. Do not add logging to interrupt, timer, syscall-entry, or context-switch hot paths. The likely fix area is prohibited/high-scrutiny and was intentionally not modified by #470.