Add SafeBoot pre-init guard for solar/low-battery nodes

[Mickyleitor]

Summary

Adds a pre-init battery guard for solar and battery nodes. Checks if we have enough juice to boot before lighting up the radio, scanning I²C, and writing to flash.

Currently the firmware only evaluates battery voltage after expensive init is done. On depleted solar nodes, that's too late — brownout mid-boot, restart, repeat forever, sometimes corrupting the filesystem along the way.

This guard runs very early in setup(), reads Vbat via quick ADC (no I²C, no PMU), and either continues boot if voltage is stable, or goes back to sleep with hysteresis and backoff until conditions improve.

Related issues

• [Feature Request]: Heltec power management. Sleeping Beauty mode. #9911 — "Sleeping Beauty" (stuck after brownout) — @roberthadow
• [Bug]: [Bug/Feature] nRF52 Solar Nodes: Inconsistent wake-up behavior and brownout risks #9699 — nRF52 solar wake / LPCOMP — @JBAU92 @sandos
• [Feature Request]: App configurable deep sleep voltage #5199 — configurable low-battery thresholds
• [Bug]: Powerloss during early boot phase kills/resets device configuration on ESP32 devices #4555 — FS corruption from early-boot power loss
• [Feature Request] Generic nRF52 LPCOMP solar wake-up, strict external radio power management, and user-defined voltage thresholds #10084 — generic LPCOMP + user-defined thresholds — @EA2OY @sandos @roberthadow

Personal note: I built an MSP430 watchdog to force-wake nodes that got stuck after brownouts: https://github.com/Mickyleitor/meshtastic_watcher — it works, but the real fix belongs in firmware.

What's included

• Early boot power guard for ESP32 and nRF52
• ADC-based voltage check (~80ms, no dependencies)
• Hysteresis + exponential backoff (120s → 600s cap)
• LPCOMP wake on nRF52 when available (~1-3µA)
• Small FS retry after unclean resets

What's NOT included

• No protobuf changes
• No runtime config yet (follow-up)
• No power subsystem refactor

What this does NOT fix (but may help indirectly)

To be clear: this guard prevents boot-loop drain when the battery is too low to complete init. It does not directly fix nodes that boot successfully but then get stuck in an unresponsive state at runtime.

However, it's very likely these issues are related. In my experience, nodes that end up in these "zombie states" — where they don't respond to the user button but come back to life after pressing RESET — probably got there because they booted with marginal power. The system came up, but with invalid or unhealthy RAM state from a partial/unstable init. The device is technically "running" but stuck. Pressing RESET clears everything and the node works again.

By preventing boots with insufficient power in the first place, SafeBoot should reduce the chances of ending up in that zombie state. If you never let the node attempt to boot until voltage is actually stable, you avoid the marginal-power init that leaves things broken.

Testing

TBD.

[jp-bennett]

This is really interesting. The first thing that comes to mind is whether we can reuse the existing battery curve to set the minimum voltages. (And make a custom curve for the devices with questionable LDO chips.) This way the battery percentages actually make sense with what the device is going to do. Going to sleep at 0% instead of randomly rebooting at 5% like it does now.

[Mickyleitor]

This is really interesting. The first thing that comes to mind is whether we can reuse the existing battery curve to set the minimum voltages. (And make a custom curve for the devices with questionable LDO chips.) This way the battery percentages actually make sense with what the device is going to do. Going to sleep at 0% instead of randomly rebooting at 5% like it does now.

@jp-bennett That's actually a good idea... I've just pushed that so SafeBoot now falls back to the existing battery OCV curve when a board doesn't provide explicit boot thresholds, which keeps early-boot protection aligned with the same voltage model already used for battery percentage and runtime low-battery handling.