fix: handle early-boot exceptions in excp_handler gracefully

excp_handler() called context::current() unconditionally, which panics
with 'not inside of context' when no context exists yet (before
context::init() runs in kmain/kmain_ap). On bare metal, a page fault
during BSP's start() — e.g. ACPI table access or device MMIO — caused
page_fault_handler() to return Err, falling through to excp_handler(),
which then panicked at context::current() instead of reporting the
actual fault.

Replace context::current() with context::try_current(). When None,
log the exception details (kind, code, faulting address) and panic
with a descriptive message. This turns an uninformative cascading
panic into a diagnostic one that reveals the real faulting address.

src/context/signal.rs

@@ -74,7 +74,21 @@ pub fn signal_handler(token: &mut CleanLockToken) {
 pub fn excp_handler(excp: syscall::Exception) {
     let mut token = unsafe { CleanLockToken::new() };
 
-    let current = context::current();
+    let Some(current) = context::try_current() else {
+        // No context exists — this happens during early boot (before
+        // context::init() in kmain) or very early in AP startup. The
+        // exception details (page fault address, stack trace, etc.) have
+        // already been printed by the caller in the exception handler.
+        // There is no userspace context to deliver a signal to, so halt.
+        info!(
+            "excp_handler: no current context (early boot), CPU {}, kind {}, code {}, address {:#x}",
+            crate::cpu_id(),
+            excp.kind,
+            excp.code,
+            excp.address
+        );
+        panic!("unhandled exception during early boot (no context)");
+    };
 
     let context = current.write(token.token());