Add filter to paired device retrieval

[hinathan]

Hello - thanks for your work on this library, it's been useful for my project. For my use case I want to be able to have connections to multiple devices connecting and disconnecting without user intervention, and regularly check for previously known ('Paired') devices, in addition to scanning for new BLE devices which match my service UUIDs.

An unexpected issue I've encountered using this code is that retrieveConnectedPeripherals(withServices:) unconditionally calls ConnectedPeripheral(...) which sets a new cbPeripheral.delegate instance on the CBPeripheral object, leaving my prior ConnectedPeripheral objects in a zombie state where they still write data without error but cannot receive data or notifications.

A filter on this call, like you already have on scanAndConnect(...) helps my code prevent this case. Feel free to change the approach here or ignore it but submitting this because it's useful for my scenario.

[Linqa2]

Thanks for the detailed PR and explanation, I think I understand the underlying issue now.

The core problem seems to be that repeated retrieval / reconnect paths can end up creating multiple logical wrappers for the same CBPeripheral, which then leads to delegate ownership being overwritten and “zombie” sessions.

I agree this needs to be addressed, but before merging this specific change I want to work on a more general solution at the BluetoothCentral level, so that wrapper identity and idempotency are guaranteed across all entry points (scan, retrieve, connect), not just this call site.

Your PR was very helpful in surfacing the real-world scenario, and I’ll follow up once I have a more universal fix in place.

UPD I've created an issue to track this, feel free to add comments or correct me if my understanding of the problem is wrong: #9

[hinathan]

Your plan to defer this change in favor of globally idempotent connections makes sense, and is probably necessary to avoid similar error modes we haven't thought of.

[Linqa2]

After thinking it through a bit more, I think the filter-based selection is useful in its own right and worth having, so I’m going ahead and merging this.
Thanks for the contribution!