Stack overflow when combo-ing lt_spc + magic_shift + lt_spc #155

Hi urob! First of all, huge thanks for your modules and keymap paradigms. I use adaptive-key, auto-layer, and your base.keymap implementation heavily across my boards.

I'm opening this just as an informational heads-up in case anyone else runs into this bizarre edge case.

The Bug:
I recently started experiencing hard kernel crashes (board disconnects/reboots over BLE, or infinite key-spamming over USB) when typing very rapidly. I managed to isolate the exact sequence to:
Space (lt_spc) -> Magic Shift -> Space (lt_spc)

Because of the deep nesting of this combo (a hold-tap triggering a mod-morph, which outputs a macro containing &sk LSHFT, overlapping with the adaptive-key outputs of magic_shift), the cascade of state-change events was completely overflowing the default ZMK/Zephyr System Workqueue stack (which defaults to 2048 bytes).

Why it's tricky:
This crash did not happen on my main wireless board (CrossesV2). It only started crashing when I brought the exact same layout over to a new board (Delta Omega) that had an RGB LED Widget enabled (CONFIG_RGBLED_WIDGET=y). It turns out the LED widget hooking into those modifier state-change listeners added just enough execution overhead to push those nested sticky-shift macros over the 2048-byte cliff!

The Solution:
Setting this in my .conf file completely fixed the crashes:
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

Given how heavily your excellent layout paradigm relies on compounding hold-taps, morphs, and sticky modifiers, I figured it was worth flagging! It might be worth documenting a recommendation for users to bump their WORKQUEUE_STACK_SIZE to 4096 if they use your modules alongside heavy event-listeners like RGB Matrices, Displays, or LED Widgets to prevent them from hitting these invisible stack overflow panics.

Thanks again for all the incredible work you do!