Try direct BLE authentication before double-connect fallback

[alexanderpett]

Summary

This PR changes the BLE mesh connection flow so pyplejd first tries to authenticate on the initial BLE connection and only falls back to the existing disconnect/reconnect workaround if that first authentication attempt fails.

The current code always does:

1. establish BLE connection
2. immediately disconnect
3. sleep 5 seconds
4. establish a second BLE connection
5. authenticate

That unconditional double-connect appears to trigger reconnect throttling or unstable mesh behavior on some setups with Plejd firmware 6.43.3.

Why

I have been troubleshooting a reproducible hass-plejd 0.21.3 / pyplejd 0.21.3 problem where:

• Home Assistant could discover and poll all Plejd devices
• the gateway device responded to commands
• commands to non-gateway devices were logged as writes but did not physically take effect until the integration was reloaded
• after removing the unconditional double-connect block, commands to mesh devices started working again

Related hass-plejd issue: thomasloven/hass-plejd#162
Related prior discussion: thomasloven/hass-plejd#154

Approach

This PR keeps the workaround available as a fallback instead of removing it completely:

• connect once
• attach the disconnect callback to that client
• try to authenticate
• if authentication fails, disconnect, wait 5 seconds, reconnect using the existing workaround path, and authenticate again

This should preserve compatibility with setups where the workaround is still needed, while avoiding an unnecessary forced reconnect on setups where the first connection is already valid.

Local validation

Validated on Home Assistant OS with hass-plejd 0.21.3 and Plejd firmware 6.43.3 using a forked pyplejd build. After the change:

pyplejd version: 0.21.3.post1
contains BT Proxy workaround: False
contains set_disconnected_callback: True

Commands to non-gateway Plejd lights now execute immediately.

Notes

This is intentionally conservative because issue #154 suggests the workaround may still be required for some combinations of hardware/firmware. The goal is to avoid the workaround when it is not needed, not to remove it entirely.

[thomasloven]

Good idea! I'll take a look at this in the next few days.