feat: add trezor send

[ben-kaufman]

Description

This PR:

1. Adds paired Trezor wallets as funding sources throughout the normal on-chain Send flow, including scanner, paste, manual entry, contacts, fee selection, confirmation, signing, broadcasting, and success handling.
2. Hardens Trezor session recovery and preserves hardware-wallet activity and contact metadata while wallet snapshots catch up.

The Send UI follows the Bitkit Wallet design.

Receive support will follow in a separate stacked PR.

Linked Issues/Tasks

N/A

Screenshot / Video

QA Notes

Manual Tests

• 1. Trezor wallet → Send → enter a Bitcoin address and amount → Continue: the button loads once, Confirm opens, and repeated taps do not duplicate preparation.
• 2. Send Confirm → choose Trezor → Sign With Device → approve on Trezor: the transaction broadcasts and Success shows the hardware-wallet activity.
• 3. Trezor passphrase wallet → Send → enter passphrase: the paired account reconnects and the operation resumes.
• 4. Trezor-funded Send → scan a Lightning or LNURL request: Bitkit explains that a Bitcoin address is required.
• 5. regression: Send → switch between Savings, Spending, and Trezor: available balance and fee-aware maximum update for each source.
• 6. regression: cancel or disconnect during signing → retry: Bitkit reconnects without creating or broadcasting a duplicate transaction.

Automated Checks

• Unit tests added or extended in HwFundingSignerTest.kt and TrezorSessionFailureTest.kt: cover source coordination, timeouts, stale-session retry, retained signed transactions, and failure classification.
• Unit tests extended in HwWalletRepoTest.kt: cover pending sent activity and contact preservation during watcher reconciliation.
• Unit tests extended in ShopPaymentRequestTest.kt: cover hardware-wallet on-chain-only scan handling.
• Hardware-wallet tests, lint, and formatting checks pass.

[greptile-apps]

Greptile Summary

The PR integrates paired Trezor wallets into on-chain send and receive flows and strengthens session recovery and hardware-activity reconciliation.

• Adds offline fee composition, device signing, safe broadcast retry, and hardware-funded send navigation.
• Adds hardware receive-address display and on-device verification.
• Extends wallet-scoped activity and contact handling for hardware transactions.
• Two lifecycle gaps remain around multi-wallet receive selection and restart-safe activity reconciliation.

Confidence Score: 3/5

The PR should not merge until multi-wallet receive selection and restart-safe preservation of newly broadcast hardware activities are addressed.

Global Receive silently loses Trezor access for users with multiple paired identities, and process-local snapshot protection can delete a newly created hardware-send activity and its contact metadata after an app restart.

Files Needing Attention: app/src/main/java/to/bitkit/ui/screens/wallets/receive/ReceiveSheet.kt; app/src/main/java/to/bitkit/services/CoreService.kt

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/ui/screens/wallets/receive/ReceiveSheet.kt	Wires hardware address loading and verification into Receive, but removes the hardware option from global Receive when multiple paired wallets require selection.
app/src/main/java/to/bitkit/services/CoreService.kt	Preserves locally created sends during watcher lag only through process-local state, allowing restart-time deletion and contact loss.
app/src/main/java/to/bitkit/ui/screens/wallets/send/HwSendViewModel.kt	Adds a guarded sign-and-broadcast state machine with signed-transaction reuse for connectivity retries and wallet-scoped result persistence.
app/src/main/java/to/bitkit/repositories/HwWalletRepo.kt	Adds offline receive derivation, device verification, fee estimation, maximum calculation, and more targeted stale-session cleanup.
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Extends request validation, amount limits, fee preparation, source switching, contact preparation, and success handling for hardware-funded sends.
app/src/main/java/to/bitkit/repositories/ActivityRepo.kt	Scopes hardware activity lookup and contact mutation to the selected external wallet identity.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Select paired Trezor] --> B[Enter on-chain request]
  B --> C[Estimate fee from stored xpub]
  C --> D[Review payment]
  D --> E[Reconnect matching wallet identity]
  E --> F[Sign on Trezor]
  F --> G[Broadcast signed transaction]
  G --> H[Create wallet-scoped activity]
  H --> I[Reconcile watcher snapshot]
  J[Open Trezor Receive] --> K[Derive unused address from xpub]
  K --> L[Display QR and address]
  L --> M[Reconnect matching identity]
  M --> N[Verify address on device]

Loading

_{Reviews (1): Last reviewed commit: "feat: add trezor send and receive" | Re-trigger Greptile}

[jvsena42]

Worth updating the journeys with the new flows

[ovitrif]

Could be split into 2 stacked PRs, one for Send, one for Receive 🙏🏻

[ben-kaufman]

Done — #1187 is now Send-only and conflict-free. Receive is split into the stacked #1189. iOS is split the same way: Send in synonymdev/bitkit-ios#688 and Receive in synonymdev/bitkit-ios#693.

[ovitrif]

Done — #1187 is now Send-only and conflict-free. Receive is split into the stacked #1189. iOS is split the same way: Send in synonymdev/bitkit-ios#688 and Receive in synonymdev/bitkit-ios#693.

Thanks, recommending to use gh-stack extension so this is done automatically from local machine via gh cli, we can also do it from the GitHub web UI but that's more streamlined.

You might need to install it first:

gh extension install github/gh-stack

[ben-kaufman]

@jvsena42 Done. The journeys are split with the implementation: send-onchain.xml is included in #1187, and receive-onchain.xml is included in the stacked #1189. The hardware-wallet journey README is updated in each layer as well.

@ovitrif Thanks for the gh-stack recommendation. I’ll use it for future stacked PR work.

[ovitrif]

Two correctness defects block this change: switching funding sources can leave confirmation enabled for an underfunded source, and cached watcher snapshots can prevent pending-send expiry from being reevaluated. I also found regressions in activity seen-state preservation and hardware-recipient coverage, plus one Kotlin import violation.