v0.8.0 — proper stale-client cleanup + reconnect diagnostics

What's new

Reconnect reliability. When the BLE link drops but the BleakClient reference is still around, the BlueZ connection slot stays allocated. Previously it was only released when a reconnect was attempted — which may never come if the device stopped advertising (MASS2 half-closed state). The main loop now detects a stale client at the top of each iteration and routes it through _disconnect() before waiting for advertisement, so the slot is freed right away.

Diagnostics. More log detail to make reconnect problems easier to investigate:

• BLE link dropped: <MAC> (uptime=Xs) at INFO when the link drops
• Stale client for <MAC> (is_connected=..., notifications=...); cleaning up when the early cleanup fires
• Disconnect timed out for <MAC> after 5s — BlueZ slot may still be allocated at WARNING if the cleanup itself hangs
• Exception class names in Live monitoring error and Failed to connect log lines

Changes

• _connect() failure path now routes cleanup through _disconnect() for consistency
• _disconnect() logs was_connected / bleak_is_connected state on failure
• Internal: track connect_time via time.monotonic() to compute uptime

Upgrading

No config changes required. If you're troubleshooting a connection problem, enable DEBUG logging for custom_components.isdt_air_ble to see the finer-grained messages.