fix(batt-led): force LED off + disarm on disconnect

The low-battery blink would stay frozen mid-cycle (or briefly resume
during reconnect retries) after a controller died and lost connection,
because the stale-report check stopped toggling but never turned the
LED off, and the cached interrupt_in_data[52] still read low.

New `battery_led_on_disconnect()` clears blink state, forces the LED
off, and zeros last_report_us so the stale-check early-return blocks
any new blink until a fresh 0x31 report arrives on the next connection.
Called from bt.cpp's HCI_EVENT_DISCONNECTION_COMPLETE handler.

Stale-check in the tick also now forces LED off when it fires while a
blink was in progress (defense in depth for unclean disconnects).

Same bug exists in upstream awalol/DS5Dongle (their battery_led.cpp is
byte-identical to ours pre-fix) — Sura Academy reported it in their
Discord. Plan to send this back as a PR after we validate it locally.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/bt.cpp

@@ -19,6 +19,9 @@
 #include "state_mgr.h"
 #include "pico/util/queue.h"
 #include "slots.h"
+#if ENABLE_BATT_LED
+#include "battery_led.h"
+#endif
 
 #define MTU_CONTROL 672
 #define MTU_INTERRUPT 672
@@ -454,6 +457,9 @@ static void hci_packet_handler(uint8_t packet_type, uint16_t channel, uint8_t *p
             hid_interrupt_cid = 0;
             feature_data.clear();
             cyw43_arch_gpio_put(CYW43_WL_GPIO_LED_PIN, false);
+#if ENABLE_BATT_LED
+            battery_led_on_disconnect();
+#endif
             printf("[HCI] Disconnected reason=0x%02X, start inquiry\n", reason);
             gap_inquiry_start(30);
             break;