pairing: Add retry logic to get_pairing_data to fix flaky test

[cdecker]

Summary

The test_pairing_session test was flaky due to a race condition in the pairing protocol.

Problem

The NewDeviceClient generates the device_id locally and sends it via the QR code channel before the PairDevice gRPC request reaches the server. When the AttestationDeviceClient immediately calls GetPairingData with that device_id, the session might not exist on the server yet, causing a KeyError.

The race happens because:

1. The Rust client creates the gRPC request future but doesn't await it immediately
2. It sends the QR data (containing device_id) to the channel first
3. Only then does it await the actual gRPC call

Solution

Add retry logic to get_pairing_data in the AttestationDeviceClient that retries for up to 10 seconds with 100ms intervals. This handles the inherent race condition in the pairing protocol where the attestation device may receive the QR code before the new device's PairDevice request has been processed by the server.

Testing

Verified with flaky test plugin - passed 10 out of 10 runs:

pytest tests/test_pairing.py::test_pairing_session --force-flaky --max-runs=10 --min-passes=10