Clear cancelled pairing requests on desktop

[enaboapps]

Closes #548

Summary

• track macOS pending pairing requests by CoreBluetooth central and remove only the cancelling phone
• clear Windows pending requests after the final BLE subscriber disconnects
• clear pending state during manual disconnect and Bluetooth teardown
• emit a sanitized cancellation activity and update the setup guide immediately

No Android or public protocol changes are required.

Validation

• npm run lint
• npm test (40 passed)
• npm run build
• cargo fmt --manifest-path src-tauri/Cargo.toml --check
• cargo clippy --manifest-path src-tauri/Cargo.toml --all-targets -- -D warnings
• cargo test --manifest-path src-tauri/Cargo.toml (129 passed)
• signed macOS debug app bundle built and passed strict codesign verification

[greptile-apps]

Greptile Summary

Pairing requests now track Bluetooth connection state more accurately across desktop platforms. macOS keeps requests isolated to the device that created them, while Windows preserves pairing state when the subscriber count cannot be read. The previously reported Windows state-loss path was exercised: an unavailable subscriber count returns before any pairing request is cancelled.

Confidence Score: 5/5

The connection and pairing-state changes preserve active-device requests and avoid clearing state when Windows connection status is unknown.

No blocking failure remains.

T-Rex Logs

What T-Rex did

• Ran an executable regression harness against Windows BLE callback implementations and observed that the former defaulted an unavailable subscriber count to zero while the current implementation returns before cancellation and does not cancel for an unknown count, and that a confirmed subscriber count of zero still follows the intentional disconnect cleanup path so an unavailable query no longer clears pending pairing requests.
• Ran an executable two-device pairing harness against the current macOS request-association and unsubscribe logic; the control scenario showed that global cancellation removes both devices' requests, while the current behavior cancelled central A's request while central B's request remained pending and associated with central B.
• The executable focused check exited 0 and reported parent_absence_default=0, parent_zero_count_reaches_cancel_all_pairings=true, current_absence_returns_before_cancel_all_pairings=true, and current_predicate_none_cancels=false; a known count of exactly zero still cancels pending pairings, and the Windows-native unit-test exited 101 with Rust error E0463, indicating the Windows MSVC target is unavailable.
• Harness and related artifacts document the before-and-after isolation scenario and show that native attempts are blocked by host dependencies, including a native Rust attempt failure due to missing dependencies.

_{Ran code and verified through T-Rex}

_{Reviews (2): Last reviewed commit: "fix: preserve unknown subscription state" | Re-trigger Greptile}