bug: savings payable requests are routed to the hardware wallet #1186

What happened?

With a hardware wallet paired, a request that Savings can pay is routed to the hardware wallet. Opening a $2.50 request (3,204 sats) while Savings holds 783,201 sats shows FROM BITKIT TEST TREZOR instead of Savings.

The Savings max-sendable estimate fails on every request open:

Failed to calculate max sendable amount … Insufficient funds (LDK: Available: 779999sats, Required: 780000sats)

SendSheet.selectHardwareFundingSourceIfNeeded (SendSheet.swift:898) then treats Savings as unavailable and picks the hardware wallet. The estimate is off by one sat, so it fails even when the request is a tiny fraction of the balance.

Expected behavior

Savings is chosen when it can cover the request plus fee. A failed max-sendable estimate should not count as "Savings cannot pay".

Steps to Reproduce

1. Pair the Trezor emulator: Settings › Hardware Wallets › Add.
2. Fund Savings with about 780k sats in a few UTXOs.
3. Receive a small Savings-only payment request from a contact, then open it.
4. The confirmation shows the hardware wallet as the source, and the log shows the max-sendable failure above.

Logs / Screenshots / Recordings

Seen on master f3e97b0 and on #1014 head 1607a10, during that PR's device gate. Combined with the two hardware composes (#1187), every request on this wallet takes about 15 s before it can be paid on 1607a10.

Bitkit Version

master f3e97b0

Device / OS

iPhone 17e simulator (iOS 26.5), Trezor emulator from bitkit-docker.

Reproducibility

Every time on that wallet.