Fix BLE reconnect leaving stale notification registration (duplicate notifications)

[joeyleake]

Fixes #97

Problem

After a BLE reconnect, every GATT notification from the device was
delivered twice. BLEConnection.connect() always overwrites self.client
with a fresh BleakClient on every call, but never tore down the previous
client first — so its GATT notification subscription (start_notify on
the UART TX characteristic) stayed registered at the BlueZ D-Bus level
alongside the new one, and every notification fired for both.

Fix

Added BLEConnection._cleanup_stale_client(), called once at the top of
connect() before any of the three client-acquisition branches
(pre-configured client / direct device / scan-by-address) replace
self.client. It best-effort disconnects an existing, connected client so
its notify subscription is torn down before a new one is created. Failures
during this best-effort cleanup are logged at debug and swallowed, since
the goal is to clear stale state, not to block a reconnect attempt on a
client that's already in a bad state.

One incidental behavior note: the previous "client is already connected!!
weird" early-return branch is now unreachable within the same connect()
call, since cleanup disconnects first. That branch previously returned
early without re-establishing the notify subscription in that edge case;
now it goes through a normal reconnect. This seems like a correctness
improvement rather than a regression, but flagging it since it's a
behavior change either way.

Testing

Added tests/unit/test_ble_reconnect_cleanup.py, which mocks BleakClient
and asserts that calling connect() twice in a row disconnects the first
client before the second one is used.

Full suite: 180 passed, 2 failed (test_send_cmd,
test_advert_path_preserves_embedded_zero_bytes) — both failures
reproduce identically on a clean main checkout and are unrelated to this
change.