[Feature request] Bounded SX1262 receive recovery policy #3720

The small in-flight TX protection fix is submitted as #3714, and counter initialization as #3715. Separately, a SuperBase fork contains bounded SX1262 receive recovery for repeated startReceive() failures. I would like feedback on the policy before proposing a larger radio change to dev.

The prototype spaces receive retries by one second and reinitializes the SX1262 after three failures. It restores frequency, bandwidth, spreading factor, coding rate, TX power, CRC, preamble and RX boost settings before resuming receive, and must never perform recovery during an in-flight TX. The current dev uses RadioLib 7.8.1, so that port and its backend contract would be validated independently rather than copied blindly from the older fork.

The fork's recovery paths have deterministic fault-injection tests and the overall implementation passed bidirectional LoRa tests on a Muzi Works SuperBase with a controlled Heltec V4 peer. This is not evidence of every physical failure mode or maximum RF range.

Would maintainers prefer a board opt-in recovery hook, a shared wrapper policy with backend-specific reinitialization, or simply bounded retry/error reporting without automatic reset? I would keep this separate from the TX guards so an agreed retry/reset policy is not hidden inside a small correctness fix.