Add V4.2 solar BLE companion with automatic recharge recovery

[n30nex]

Add an opt-in heltec_v4_solar_companion_ble candidate for a Heltec V4.2 with a 5000 mAh single-cell LiPo and regulated 5 V solar input. It retains standard MeshCore BLE/MeshMapper compatibility and continuous LoRa receive, uses continuously connectable 250–300 ms BLE advertising, enables controller modem sleep and 40–80 MHz CPU scaling, and keeps the screen timeout at 15 seconds.

Replace permanent low-battery shutdown in this target with three-sample 3.40 V cutoff, 60-second timed recharge checks before peripheral/storage startup, and two-reading 3.70 V recovery qualification. Brownout/watchdog resets use recharge qualification. Timer setup failure restarts instead of entering indefinite sleep; startup faults retry and a 30-second task watchdog covers the running application. Save a generated pairing PIN once so recovery does not require reading a new PIN from an inaccessible display. Existing saved settings/PINs are preserved and nonblank storage is never reformatted automatically.

The solar target uses the SHA-256-verified IoTThinks power-saving Arduino 2.0.17 core; other profiles retain their existing framework. CPU light sleep remains disabled pending hardware IRQ/USB qualification, keeping phone availability and LoRa interrupts continuous. CI adds the solar image plus the original V4 BLE regression build and battery-policy tests.

The installation guide identifies the V4.2 charger limit (~540 mA), lack of onboard cell-temperature sensing in the published schematic, candidate status, and required reconnect/current/recharge/brownout/overnight tests. Actual current, daily charge balance, MeshMapper/phone latency, cold-charge protection, and physical recovery are unverified. This PR creates firmware for bench qualification; it does not flash hardware or publish a production release.

Validation for 183a0eec45e440f9cd0a496884e5a3247a90c78d:

• V4 build workflow: all seven firmware profiles, native tests, embedded WebUI, and required firmware gate passed. The solar and original BLE profiles both produced application and recovery images.
• Unit test workflow: 41 tests passed, including eight solar battery-policy tests. Both branch-required checks passed.
• Downloaded Actions artifacts verified against all five SHA-256 entries. The source archive identifies the exact commit and all 12 changed files match it. ESP32-S3 image identity, firmware version, application offset, and identical embedded application verified. The partition table matches the stock BLE regression image, and the merged image ends before stored MeshCore settings.
• The broader cross-board Build Check has 12 passing targets and two failures outside the V4 scope: PicoW's downloaded Arduino framework pulls an iLabs Hearth library requiring ESP_SERIAL_PORT, and unchanged STM32 TxtDataHelpers.cpp uses unavailable ltoa. Those targets/dependencies were not changed or their checks bypassed. This is not an all-green cross-board CI claim.
• USB-only hardware check on a user-identified V4.2: the exact Actions application was flashed after a verified 16 MiB backup. Full-flash verification confirmed all bytes outside the application erase range were preserved. A 45-second observation showed one clean startup, watchdog ready, and both BLE modem sleep and CPU frequency scaling returning ESP_OK. The user confirmed a working phone connection. Neither battery nor solar was connected, so battery-voltage calibration, recovery, sustained RX, measured current, timed reconnects, and overnight/daytime charge tests remain unverified.