fix: use fast fee for savings transfer

[piotr-iohk]

Fixes #1034

This PR makes savings → spending channel funding use a faster on-chain fee rate, matching the “~10 minutes” copy and iOS behavior.

Description

• Defaults savings → spending funding to the fast fee tier instead of the settings default.
• Reserves a fast send-all mining fee when sizing max transfer, so “transfer all” leaves room to pay the order on-chain (fixes the tight-balance failure mode seen in multi_address_2).
• Aligns send-all with iOS: drain only for real dust change; fixed-send failures toast without surprise-draining the wallet.
• Prepares and shows the real mining fee on confirm before swipe, and pays funding from viewModelScope so broadcast + paid-order caching are not cancelled by Compose scope teardown.

Preview

N/A

QA Notes

Manual Tests

• 1. Funded savings wallet → Transfer → Spending → confirm max amount: funding tx uses a fast-tier sat/vB (check explorer), not the settings mid/default when that mid is ~1.
• 2. Transfer → Spending → use max → confirm: order is sized with mining-fee headroom and funding succeeds (no coin-selection / insufficient-funds toast on a normal fee market).
• 3. Tight multi-UTXO balance (transfer all) → Transfer → Spending → confirm: channel funding progresses; leftover is not left as an unaffordable fixed send.
• 4. regression: Transfer → Spending with a partial amount well below balance: still funds with a normal (non-drain) send when change is above dust.

Automated Checks

• Unit tests added: fast mining-fee reserve on max sizing; dust send-all; no drain when normal fee leaves non-dust change; fixed-send failure without drain, in TransferViewModelTest.kt.
• Local: just test file TransferViewModelTest.
• CI: standard compile, unit test, and detekt checks run by the PR bot. E2E multi_address_2 should pass once this lands on the resolved e2e branch.

[greptile-apps]

Greptile Summary

This PR updates savings-to-spending transfers to use fast on-chain fees. The main changes are:

• Reserves one fast mining fee when calculating the maximum transfer.
• Prepares coin selection and mining fees before confirmation.
• Drains the wallet only when fixed sending would create dust.
• Shows the mining fee and waits for fee preparation before confirmation.
• Adds tests for fee fallback, maximum sizing, and send-all behavior.

Confidence Score: 5/5

This looks safe to merge.

• The maximum calculation now starts from raw spendable balance and reserves one fast mining fee.
• Fee-estimation failure now uses an explicit fallback reserve.
• No blocking issue remains in the updated fee-reservation flow.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/viewmodels/TransferViewModel.kt	Uses fast-fee reservation, prepared coin selection, and dust-aware wallet draining for savings transfers.
app/src/main/java/to/bitkit/repositories/LightningRepo.kt	Adds a repository wrapper for algorithm-specific UTXO selection.
app/src/main/java/to/bitkit/ui/screens/transfer/SpendingConfirmScreen.kt	Displays the prepared mining fee and blocks confirmation until it is ready.
app/src/test/java/to/bitkit/viewmodels/TransferViewModelTest.kt	Adds coverage for fast-fee reservation, fallback sizing, dust draining, and fixed sends.

_{Reviews (3): Last reviewed commit: "Merge branch 'master' into fix/1034-savi..." | Re-trigger Greptile}

[jvsena42]

Code is good, just need some style changes