Recover the radio by re-initialising it instead of reporting a fault

[caveman99]

Targets this PR's branch. Builds on the assert removal by making the recovered-from state actually recover.

WRONG_MODEM from a LoRa-only setter does not mean anything put the chip into FSK. RadioLib checks the packet type first, and getPacketType() discards the SPI result:

uint8_t SX126x::getPacketType() {
  uint8_t data = 0xFF;
  this->mod->SPIreadStream(RADIOLIB_SX126X_CMD_GET_PACKET_TYPE, &data, 1);
  return(data);
}

So a failed read leaves 0xFF, which is not PACKET_TYPE_LORA, and every LoRa setter returns WRONG_MODEM. The error covers three cases: the chip really is in FSK, SetPacketType was never issued because begin() did not complete, or the chip is asleep/unresponsive. Recording a critical error leaves it in that state, which is what issue meshtastic#11220 reports: a T3-S3 flashed fresh, region UNSET, then a runtime region change fails every setter and the region reverts.

Changes:

• the three runtime SPI sites and a WRONG_MODEM during reconfigure() request recovery instead of recording a fault, in all five interfaces
• loop() tears the interface down and runs initLoRa() again, generalising what the Portduino daemon already did for portduino_status.LoRa_in_error
• the ISR is detached before the interface is destroyed, since ~RadioLibInterface only clears instance and setDio1Action would otherwise be left pointing at freed memory

Only WRONG_MODEM arms recovery from reconfigure(). An out-of-range setting still records INVALID_RADIO_SETTING on its own, because re-initialising cannot fix operator config and would retry forever.

On embedded targets a second failed attempt reports NO_RADIO and stops retrying. Portduino keeps its existing reboot, and its CH341 re-enumeration stays Portduino-only.

Not tested on hardware; the failure it targets needs a device that reproduces meshtastic#11220.