feat: connect hardware flow

[ovitrif]

Closes #1027
Refs #998

This PR adds Bitkit's Connect Hardware flow for pairing a Trezor as a watch-only hardware wallet from the Home hardware suggestion, Hardware Wallets settings, or Android's USB "Open with Bitkit" chooser.

Description

• Adds the guided in-sheet pairing flow: Intro → Searching → Found → Paired, covering device discovery, connect confirmation, balance display, editable Label Funds, and Finish.
• Supports USB and BLE discovery from the same flow. USB discovery can run without BLE access; BLE scanning requests the required runtime permissions, prompts to enable Bluetooth when it is off, and shows a Settings recovery dialog if permissions were denied.
• Handles Android USB attach intents for supported Trezor devices so choosing Bitkit from the OS chooser can open directly on the Found Device step, then refreshes USB discovery before connecting.
• Shows the one-time THP pairing code step inline when a device asks for it, with the PIN characters collapsing into the submit spinner while pairing completes.
• Persists the Bitkit-side Label Funds value per hardware wallet and applies it consistently across USB/BLE entries for the same wallet.
• Keeps compact hardware wallet surfaces resilient by capping/editing long labels so the Home tile and connection indicator remain usable.
• Keeps the flow sheet-native: cancel/back dismisses the sheet, the Searching step uses the Figma dashed-ring loading animation, and the Paired step follows existing sheet layout/button patterns.
• Reconnects known devices silently when USB/BLE transport becomes available again and updates connection indicators when transport is lost.

Figma Designs:

• Connect Hardware flow

Preview

Connect via Android OS chooser when USB is attached & using BLE via settings screen:

Normal Speed	2x Speed
hwconnect.mp4	hwconnect2x.mp4

Connect via suggestion card:

hwviacard.mp4

QA Notes

Figma does not include a dedicated pairing-code screen, so that step follows Bitkit's existing in-sheet patterns.

Manual Tests

• 1. Home → Hardware suggestion card → Continue: in-sheet nav runs Intro → Searching, shows the dashed-ring loader, then advances to Found when a device is discovered.
• 2. Settings → General → Payments → Hardware Wallets → Add Hardware Wallet: the same connect flow opens and pairs a Trezor.
• 3. Android USB chooser → Open with Bitkit for a supported Trezor: Bitkit opens the hardware sheet on Found Device; Connect pairs the device without going through Intro first.
• 4. BLE permission/Bluetooth unavailable → Continue: USB search still starts; BLE access is requested gracefully, Bluetooth enablement is prompted when needed, and denied permissions can be recovered via Settings.
• 5. Found → Connect → Paired: shows the device balance and editable Label Funds field; Finish closes the sheet and the Home hardware tile / Settings list show the entered label.
• 6. Physical first-ever pair → Pair Device: enter the 6-digit code; the code row collapses into the spinner, then the flow advances to Paired.
• 7. regression: Back gesture or Cancel from Intro / Searching / Found / Paired: dismisses the sheet instead of stepping backward through completed connect screens.
• 8. regression: Disconnect/reconnect USB or toggle Bluetooth for a known device: the hardware connection indicator turns grey when unavailable and green again after silent reconnect.

Automated Checks

• Unit tests added/updated in HwConnectViewModelTest.kt: cover Intro→Searching discovery with and without Bluetooth, Found-route USB refresh before connect, Connect→Paired, inline pairing-code navigation, balance updates, label capping, and Finish persistence.
• Unit tests added/updated in HwWalletRepoTest.kt: cover scan/connect delegation, Label Funds persistence/clearing across transport entries, and wallet-name resolution.
• Unit tests added/updated in TrezorRepoTest.kt, TrezorTransportTest.kt, and AppViewModelSendFlowTest.kt: cover setup gating before scan/connect paths, quiet USB opens, BLE-scan opt-out, USB attach handling, and app-wide pairing-code routing.
• Journeys added/updated: connect-flow.xml, suggestion-intro-sheet.xml, and usb-reconnect.xml cover the Settings Add flow, Home suggestion flow, and USB attach reconnect path.
• Ran locally: just compile, just test, just lint, and git diff --check.
• GitHub checks: lint/detekt passed for the latest head; CI/E2E jobs were skipped by workflow conditions.

[ovitrif]

Re-enable pairing input after a failed code

When the user enters a wrong pairing code, or the connect attempt fails after the code is submitted, this local submitted state stays true and the number pad remains disabled with the spinner showing.

Handled by returning the flow to Found when connect fails, including failures after the pair-code step, so the stale local submitted/spinner state is discarded and the user can retry Connect. The sheet reset/cancel path now also cancels any pending pairing-code request. Added coverage in HwConnectViewModelTest.

Resolved in d35810d

[piotr-iohk]

Testing (Samsung S22, Android 16, Trezor Safe 7, fresh install)

• Connect via USB — OK. Device found, Connect advances to pairing code (first THP pair), then Paired.
• Connect via BLE — Fails on Found → Connect. BLE search finds Trezor Safe 7, but Connect does not advance (no pairing code / Paired). Logs show connect enumerate with BLE disabled → 0 devices → Trezor connect failed. Likely cause: USB-only rescan before connect runs for BLE-discovered devices too (onFoundRoute always sets scanUsbBeforeConnect).
  Artifacts: recording + logs attached below.

Screen_Recording_20260622_111352_Bitkit.Regtest.mp4

bitkit_logs_2026-06-22_09-14-36.zip

Suggested fix: only USB rescan before connect for /dev/... ids (USB attach); enable BLE enumerate during connect for BLE device ids.

[ovitrif]

BLE search finds Trezor Safe 7, but Connect does not advance (no pairing code / Paired). Logs show connect enumerate with BLE disabled → 0 devices → Trezor connect failed.
Suggested fix: only USB rescan before connect for /dev/... ids (USB attach); enable BLE enumerate during connect for BLE device ids.

Fixed by limiting the USB pre-connect rescan to Android USB attach route ids (/dev/...). BLE-found devices now connect directly with the discovered BLE id, and HwConnectViewModelTest covers both the USB attach route path and BLE route path.

Resolved in 7ca386e

Also investigating why I didn't encounter this bug during testings, given that I also connected first with USB then tested BLE in same session, while USB connection was known.