Fix integration stuck initializing on stray BLE bytes or link loss during auth

[GnoX]

This PR fixes the integration getting stuck "initializing" indefinitely when the BLE auth handshake hit an unrecoverable state during the ECDH key exchange and never reached a terminal state, leaving async_setup_entry waiting forever. Three separate gaps each let a transient BLE hiccup wedge setup:

• Stray notification bytes aborted the handshake. SimplePacketAssembler.parse raised PacketParseError on a notification with no \x5a\x5a prefix or only CRC-invalid candidates - typically leftover bytes from the previous encrypted session on a freshly reconnected link. It now returns None ("wait for the next notification") like the encrypted EncPacketAssembler already does, so a stray notification can't abort auth and spin the reconnect loop.
• Retrying a dead transport hung auth. When the link dropped mid-request (BlueZ Remote peer disconnected from start_notify), sendRequest retried on a transport that was already gone, and bleak doesn't always fire its disconnected callback for a synchronous GATT failure. It now detects the lost link and drives disconnected() itself - scheduling a reconnect, idempotent with bleak's callback.
• The setup auth wait had no deadline. async_setup_entry is now bounded by asyncio.timeout(timeout) (the same connection timeout, matching the config flow) and disconnects on failure, so a stalled handshake surfaces as ConfigEntryNotReady and HA retries cleanly.

Should resolve #367 and also #366

[rabits]

Yeah those ble issues are quite hard. I hope this will help... Great change!