fix: remove BLE packet deduplication causing chacha20poly1305 auth failure

[dfx01]

Root Cause

The seenPackets deduplication logic in BLEConnectionContext incorrectly drops legitimate BLE packets whose payload happens to match a previously received packet.

In the Noise Protocol (which uses chacha20poly1305), encrypted packets can legitimately produce identical 64-byte payloads — for example short ACK or response frames. When such a packet was silently dropped, the Noise cipher's read buffer became incomplete and MAC verification failed:

panic: chacha20poly1305: message authentication failed

This manifests specifically when calling GetETHAddress (and likely other operations) after a successful connection and channel hash verification, because those later calls are more likely to produce short encrypted response frames.

Fix

Remove the content-based deduplication entirely from didUpdateValueFor.

CoreBluetooth's didUpdateValueFor delegate is only called once per actual peripheral notification — it does not deliver duplicate notifications. Deduplication at this layer is therefore both incorrect (breaks the Noise cipher) and unnecessary (CoreBluetooth already handles it at the BLE stack level).

Changes

• Removed seenPackets: Set<Data> field from BLEConnectionContext
• Removed duplicate-check logic in didUpdateValueFor
• Removed ctx.seenPackets.removeAll() from clearReadBuffer()

Testing

The fix allows GetETHAddress and other post-pairing operations to complete successfully by ensuring all BLE packets reach the Noise cipher in order.