nrf52: fix LittleFS-in-loop() stack overflow via larger loop_task stack

[disq]

Fix nRF52 stack overflow on LittleFS file opens from loop()

Problem

nRF52 repeaters crash / go silent after admin or session activity (reproducible on dev_plus with MESH_PACKET_LOGGING + MESH_DEBUG on a RAK3401). It's a stack overflow on the framework's Arduino loop_task:

• The Adafruit_nRF52_Arduino framework runs loop() on loop_task with a 4KB stack (LOOP_STACK_SZ = 256*4).
• the_mesh.loop() → ClientACL::saveSessionKeys → Adafruit_LittleFS::open() puts large lfs_dir/lfs_info structs on the stack; measured peak ~4.7KB overruns the 4KB chunk and corrupts the heap object directly below it (observed: the RadioLib Module*), causing a hardfault/lockup.

The LittleFS v1.6 → v1.7.2 upgrade is the trigger: it enlarged the file-open path's stack footprint enough to cross the 4KB limit. That's why this reproduces on dev_plus (LittleFS 1.7.2) but not on dev (still 1.6).

This root cause is general to every nRF52 build that touches the filesystem from loop() — repeater, room server, and BLE/USB companion alike — not repeater-specific.

Fix

Give loop_task a bigger stack via a build flag, covering all nRF52 examples at once with no per-example code:

• -D LOOP_STACK_SZ=2048 (2048 words = 8KB; measured peak ~4.7KB + headroom) in [nrf52_base].
• The framework's LOOP_STACK_SZ was an unconditional #define, so the flag alone was discarded (-Wmacro-redefined). This PR therefore pins the framework to a build with a one-line #ifndef guard that makes the value overridable: Make LOOP_STACK_SZ overridable from the build (#ifndef guard) Adafruit_nRF52_Arduino#1.

Dependency / pin

Interim-pinned to disq/Adafruit_nRF52_Arduino@f019297 (= the current meshcore-patches 724e00a + the #ifndef guard). Once weebl2000/Adafruit_nRF52_Arduino#1 is merged and tagged, repin [nrf52_base] back to weebl2000/... at the new tag.

Validation

Built against the pinned guarded framework — RAK_3401_repeater (the exact MESH_PACKET_LOGGING+MESH_DEBUG crash config) and Xiao_nrf52_companion_radio_ble — both build cleanly with no -Wmacro-redefined, confirming the 8KB override is honored across nRF52 examples including BLE companion. With the default (no -D) the framework stack is unchanged at 4KB.

On-hardware: flash a RAK3401/RAK4631 repeater and drive the previously-crashing workload (admin sync, neighbour discover, repeated LoRa status requests) for several minutes — expect no LoRa-silence / lockup. Optional gdb: walk the 0xa5a5a5a5 canary from loop_task's pxStack — expect the high-water mark well under 8KB.

Supersedes

This replaces the per-example FreeRTOS worker-task approach (PR #40) with a single framework-level fix that covers all nRF52 builds.