Fix config entry FAILED_UNLOAD on hung BLE disconnect, add disconnect tracing

[GnoX]

BleakClient.disconnect() can block until the connect timeout (default 20s) when a write-with-response is still pending on the transport after a mid-auth BLE drop, which is common through an ESPHome proxy. Connection.disconnect() awaited it with no deadline, so async_unload_entry could outrun HA's unload window and leave the entry in ConfigEntryState.FAILED_UNLOAD - which only a full restart recovers from, re-triggering the same flap.

Every client teardown now goes through a bounded _disconnect_client() helper (asyncio.timeout, DISCONNECT_TIMEOUT = 5s) that swallows the usual "already down" errors and, on timeout, gives up waiting and lets the caller finish local cleanup - the transport drains on its own once the drop is detected. This enforces the deadline in the library where the hang actually happens, so all five teardown paths benefit and no async_unload_entry guard is needed.

While here, make disconnects traceable from a diagnostics download alone (no debug logging required), since the original report was hard to pin down:

• disconnect() and the bleak disconnected() callback record the caller chain as the reason on the DISCONNECTING / DISCONNECTED entries in connection_state_history, so a requested disconnect (unload, reload) is distinguishable from an unsolicited bleak drop.
• _disconnect_client() records each outcome (ok / timeout / already_down) with its trigger into a bounded disconnect_log that is included in the diagnostics dump, so timeouts and which path caused them are visible across every teardown path.

Resolves #338. Reimplements #339 with the fix moved into the library and the root cause framed correctly.
Should also address #366 #367

[rabits]

Thank you! Looks great