cjkas c1b47f898c fix: give every NVS user its own Preferences handle ... loop() and the async web server task shared one global Preferences. A begin() from one task failed while the other had a namespace open, and the clear() or remove() after it then hit the other task's namespace: saving the radio settings while a command committed its rolling code could erase every rolling code. Each function now opens NVS with a local Preferences. NVS serializes access internally and the destructor closes the handle, so no lock is added (see docs/adr/0001). No new tests: nothing here builds natively, and deleting the global makes any missed use a compile error. The read-then-commit races on rolling codes across tasks remain and are tracked in docs/KNOWN_ISSUES.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>		2026-10-12 20:51:05 +02:00
..
adr	fix: give every NVS user its own Preferences handle	2026-10-12 20:51:05 +02:00
KNOWN_ISSUES.md	fix: give every NVS user its own Preferences handle	2026-10-12 20:51:05 +02:00