fw/kernel: classify MemManage stacking faults as stack overflows

mem_manage_handler_c() only detects a stack overflow by checking
whether MMFAR points into a stack guard region, gated on MMARVALID.
A stacking fault (MSTKERR) -- exception entry pushing the frame after
SP already overflowed into the guard -- never writes MMFAR, so it took
the generic path and fault_handler_dump() dereferenced stacked_args
inside the NoAccess guard region. That second fault escalated to a
HardFault and rebooted the whole watch, so an app overflowing its
stack on every launch looped the watch into the bootloader's PRF
fallback instead of just being killed.

Treat MSTKERR as a stack overflow directly. The stack overflow path
already avoids reading the stacked frame when MSTKERR is set.

Fixes FIRM-3949

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Joshua Jun <lets@throw.rocks>

Author: jplexer

src/fw/kernel/fault_handling.c

@@ -351,6 +351,14 @@ static void mem_manage_handler_c(unsigned int* stacked_args, unsigned int lr) {
       }
     }
   }
+  // A stacking fault (MSTKERR) never writes MMFAR, so the guard-region check above cannot see
+  // it. Exception-entry stacking only faults when SP has already overflowed into a guard region,
+  // so classify it as a stack overflow. Without this we'd take the generic path below and fault
+  // again dereferencing stacked_args inside the NoAccess guard, escalating an app stack overflow
+  // into a HardFault reboot.
+  if (mmfsr & (1 << 4) /* MSTKERR */) {
+    stack_overflow = true;
+  }
 
   // If it's a stack overflow, backup the stack so that attempt_handle_hardware_fault() can jam in
   // our landing zone to return to