Prevent boot buttons from hiding recoverable Tubes

[theysayheygreg]

What this fixes

Some Tubes can look completely dead—no LEDs and no network—even though the controller is still alive. A dirty, worn, or stuck hardware button can be read during power-on as a request for rescue mode, which intentionally disables those visible signs of life. In dusty field conditions, that can make usable hardware look disposable.

This change keeps the useful USB-serial rescue path but stops any button state during power-on from entering rescue mode. Normal button behavior after startup, including existing Wi-Fi/reset gestures, remains intact.

It also reports when a configured momentary button stays active for 10 seconds, so diagnostic tools can explain that the button may be stuck instead of calling the device dead.

Technical details

• removes boot-time GPIO/button rescue admission for all targets;
• preserves the bounded serial rescue command;
• monitors configured digital momentary buttons without blocking the main loop;
• resets diagnostic timers when pin/type configuration changes;
• emits bounded machine-readable states: AVAILABLE/INACTIVE, STUCK_BUTTON, and explicit disabled states;
• adds WLED_DISABLE_STUCK_BUTTON_DIAGNOSTICS for test builds that should opt out;
• does not change platformio.ini, packet contracts, normal button handling, or physical-device state.

Verification

• focused boot/rescue diagnostic contract: pass
• ./test/tubes_mesh/run.sh: pass
• ./test/tubes_upgrade/run.sh: pass
• npm test: 16/16 pass
• firmware builds: Dig2Go-class ESP32, ESP32-C3, and ESP32-S3 pass
• git diff --check: pass
• independent C++/style review: pass, no blockers

No devices were accessed or flashed.

[SteveEisner]

This diagnostic is called on every main-loop iteration in every WLED build, and this loop scans all WLED_MAX_BUTTONS slots even when only one button is configured. The unused-slot branch also rewrites four static arrays on every pass, so ESP32 builds can do 31 unused iterations per loop while ESP8266 builds pay the RAM and flash cost even though their rescue window is disabled. Please compile-gate the diagnostic to builds where it applies, iterate only over configured buttons, and throttle sampling to a modest interval such as 100 ms; a ten-second detector does not need hot-loop polling.

[SteveEisner]

This resets reportedStatus after the button recovers, but reportedHealthy remains true from the initial AVAILABLE/INACTIVE report. The sequence AVAILABLE -> STUCK_BUTTON -> inactive therefore emits no recovered or healthy state, leaving the last reported state as STUCK_BUTTON. Please model the status as an explicit transition, or at minimum re-arm the healthy report when entering the stuck state, and add a behavioral test for the complete inactive -> stuck -> recovered sequence.