Fix unreachable reconnect-warning threshold (review follow-up, issue #119)

The 60s/5-reconnect window from the original fix could never actually
fire: consecutive reconnect attempts are never closer together than one
summary poll interval (30s) plus the 5s reconnect pause, so at most ~2
timestamps can ever land inside a 60s window regardless of how unhealthy
the connection is. That silently downgraded every reconnect to INFO
permanently, including the persistently-broken case the change was
supposed to still surface at WARNING.

Widen to a 300s window with a threshold of 3, which is reachable under
sustained failures and still a reasonable proxy for the README's
"actually broken" case.

custom_components/localthings/coordinator.py

@@ -90,11 +90,18 @@ class LocalThingsCoordinator(DataUpdateCoordinator[dict[str, Any]]):
     # drops the DTLS session briefly every now and then, and the
     # coordinator recovering from that on its own isn't something a user
     # needs to see at WARNING. Only escalate once reconnects pile up
-    # within a short window, matching the README's own "more than a
+    # within a trailing window (issue #119).
-    # handful per minute" definition of an actually-broken connection
+    #
-    # (issue #119).
+    # The window can't be a literal 60s: consecutive reconnect attempts are
-    _RECONNECT_WARN_WINDOW_S: float = 60.0
+    # never closer together than one summary poll interval (SUMMARY_INTERVAL_S,
-    _RECONNECT_WARN_THRESHOLD: int = 5
+    # 30s) plus _RECONNECT_PAUSE_S, so at most ~2 can ever land inside a 60s
+    # window regardless of how unhealthy the connection is -- a threshold of
+    # 5 there could never fire, silently downgrading every reconnect
+    # (including a persistently broken one) to INFO forever. 300s/3 instead:
+    # reachable under normal polling, and 3 reconnects inside 5 minutes is
+    # still a reasonable proxy for the README's "actually broken" case.
+    _RECONNECT_WARN_WINDOW_S: float = 300.0
+    _RECONNECT_WARN_THRESHOLD: int = 3
 
     # A block-level ACK timeout on the summary GET doesn't prove the
     # session is dead (see _poll_once) — require this many in a row