fs: serialize littlefs access with a recursive mutex

[faisal-shah]

Problem

littlefs is not thread-safe, but Controllers::FS is called from three different FreeRTOS tasks with no serialization:

• BLE host task: FSService runs full littlefs I/O (open/read/write/delete/mkdir/rename) directly inside GATT access callbacks (FSService.cpp).
• Display task: settings and alarm saves (SettingDisplay.cpp, Alarm.cpp via SaveSettings()/SaveAlarm()), watchface resource loading.
• SystemTask: fs.Init() and controller loads at boot.

The SpiMaster semaphore only serializes individual SPI bus transactions. The shared lfs_t state (block caches, open-file mlist, lookahead buffer) is unprotected, so e.g. a companion app uploading resources over the BLE FS service while the user flips a setting has two tasks inside littlefs at once, which can corrupt filesystem state.

Fix

Add a FreeRTOS recursive mutex to FS, taken in every public method, and expose a RAII FS::Lock so callers can hold the lock across multi-call sequences. The recursive type is what makes the RAII guard composable: a caller holding FS::Lock still goes through the locked public methods.

Holding the lock across a sequence matters wherever an open file handle must not race a Rename or Delete of the same file: lfs_dir_commit invalidates such handles in the mlist (lfs.c, mlist update on LFS_TYPE_DELETE), so an unlocked reader can otherwise end up on reclaimed blocks.

Existing call sites need no changes.

Cost

One recursive mutex (created in the constructor) and one handle pointer. No API change. Tasks that never overlapped are unaffected; overlapping tasks now briefly block instead of interleaving inside littlefs.

Testing

• Compiles for the target on top of current main (arm-gcc 10.3, no size surprises: +~900 B text).
• Exercised in InfiniSim with concurrent filesystem access from multiple threads under AddressSanitizer (200 wake/sleep cycles with continuous parallel FS traffic), no findings. Note InfiniSim's FreeRTOS shim needs xSemaphoreCreateRecursiveMutex/TakeRecursive/GiveRecursive implementations to build this; I have that as a small companion change for InfiniSim and can PR it there if this direction is acceptable.

Marked draft for feedback on the approach; happy to adjust (e.g. per-method granularity or a different guard shape) if maintainers prefer.

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	385792B	560B
data	944B	0B
bss	22648B	8B

Run in InfiniEmu

[faisal-shah]

The build-simulator failure is the expected cross-repo coupling: that CI job clones InfiniSim main, whose FreeRTOS shim does not implement the recursive mutex API yet. Companion PR: InfiniTimeOrg/InfiniSim#199 (additive, safe to merge independently). Once it lands, re-running the job here goes green; I verified the combined build locally in the same configuration the CI job uses.