Fix: CC1101 radio stays permanently disabled after an init hang (radioInit stuck false)

[bledrunner]

Problem

After the ESP reboots while the CC1101 radio is being initialized (e.g. a WDT reset mid-init), the web UI and the Home Assistant websocket keep working, but shades stop responding to any command from the UI or HA. Rebooting does not help — every boot behaves the same. Only the original Somfy remote still works, and only a /saveRadio POST brings the radio back.

Matches user reports such as #535 ("not responding after some times").

Root cause — transceiver_config_t::apply() in Somfy.cpp

radioInit = pref.getBool("radioInit", true);
pref.putBool("radioInit", false);   // marked in-progress
this->radioInit = false;
pref.end();
if(!radioInit) return;              // <-- returns WITHOUT resetting the flag
... CC1101 init ...
pref.putBool("radioInit", true);    // only reached on a completed init

The flag is written false before init and back to true after, so that a hang during init is detected on the next boot. But the detection path (if(!radioInit) return;) never writes the flag back to true. Once it is false, every subsequent boot reads false and skips radio init forever. The radio stays dead until a manual /saveRadio.

Fix

• Retry init for up to 3 consecutive incomplete boots (tracked in a new initCrashes NVS counter) and only then give up — booting cleanly with the radio off to avoid a hard boot loop with genuinely dead hardware. The counter resets on a successful init or a /saveRadio POST.
• SomfyRemote::getNextRollingCode() no longer advances the stored rolling code while radioInit is false, so commands issued during the dead window don't drift the code ahead of the motor and desync the remote once the radio recovers.

Notes

• Reproduced/diagnosed against a live device running v2.4.7 (= this commit).
• Not compile-tested (no ESP32 toolchain available at the time of writing); the change is localized to the two functions in the diff.