feat: pay onchain address from spending balance

[coreyphillips]

Description

Stacked on feat/savings-swap. Targets that branch, not master.

Sending to an onchain address for an amount larger than the Savings balance currently dead-ends on an "insufficient savings" toast, even when the Spending balance could cover it. This adds a fallback: pay the address out of Spending through a Boltz reverse swap, using the recipient's address as the swap claim address so Boltz's payout lands on them directly.

Ports bitkit-android #1101. The review screen stays as it is apart from one change: "From" reads Spending, and "Confirming in" gives way to a single Service fee cell, mirroring SavingsConfirmView.

• New SendSwapService owns the swap business logic: quoting, bounds, and the pay-then-await-claim orchestration. TransferViewModel keeps its own direct BoltzService use for the transfer to savings.
• boltzCreateReverseSwap prices from the Lightning invoice amount, while a send starts from what the recipient must receive, so the quote here inverts Boltz's forward formula. It ceils the percentage fee to match ReverseFees in boltz-client, not the round-to-nearest the savings quote uses. The service fee shown is invoiceSat - deliverSat.
• Boltz reports the amount it will lock before anything is paid, so a swap that would short the recipient is abandoned before the invoice is ever paid. The hold invoice amount is checked against the quote, and the recipient address is re-validated for network, before paying.
• isSwapSend is orthogonal to selectedWalletToPayFrom, which stays .onchain: the recipient is still an address and the whole send flow keys off the onchain invoice. This avoids a third WalletType case that ~50 non-exhaustive == .lightning sites would silently mishandle.
• The amount screen raises its input cap to what a swap can deliver so an amount above Savings can be entered, and the send falls back to Savings automatically once the amount fits there again (keeping the bounds so it can be raised past Savings again without a fresh scan).
• Per-keystroke pricing is sequence guarded so a slow re-price cannot overwrite the current quote, and an unpriceable swap surfaces an error rather than wedging the review screen.
• Gated behind the existing isSwapEnabled dev toggle (mainnet plus "Enable Savings Swap" in Dev Settings), so nothing changes for users yet. No changelog fragment, matching how the savings swap was gated in ad93ba38.

Not in scope, worth a follow-up:

• The payment shows in Activity as a Lightning SENT row for the gross amount. The activity is keyed on the hold invoice's payment hash and does carry the recipient address; the onchain claim tx that pays the recipient is one ldk-node never sees.
• BoltzSwap carries no intent field, so a send swap and a savings swap are indistinguishable in history.
• The claim fee rate is the global one boltzStartSwapUpdates was started with, so the send has no per-payment speed choice. The Fee and speed cell is not editable for a swap.

QA Notes

Manual QA is mainnet only: Env.isSwapSupported is network == .bitcoin, and Boltz's mainnet reverse minimum is around 50k sat. Use a wallet with an open channel holding well above that and a near-empty onchain balance, then enable Dev Settings -> Swaps -> Enable Savings Swap.

1. Scan an external onchain address (no amount) and type an amount above Savings but within Spending. The amount screen should accept it and show Spending as available, then fall back to Savings if you lower it back down.
2. Scan a BIP21 with an amount above Savings but within Spending. The send should open straight into the swap.
3. Review should read "From: Spending" with a Service fee cell next to Fee and speed. Swipe to pay.
4. Verify on an explorer that the claim transaction pays the recipient at least the amount entered. Dev Settings -> Swaps lists the swap and its claim txid.
5. Regression, dev flag off: an over-balance onchain send must still show the insufficient savings toast and go nowhere. Normal in-balance onchain sends and normal Lightning sends must be unchanged.

Tests: new SendSwapTests.swift covers the inverse fee math (exact round-trip, ceil boundary, min/max limits, spendable balance, a range of fee schedules, a degenerate non-finite schedule), the savings-versus-swap resolution including keeping bounds on revert, and the swaps-disabled fallback.

Ran the BitkitTests unit suite: all green apart from the two pre-existing UtxoSelectionTests cases that depend on the Blocktank regtest faucet (currently returning 404 for everyone, unrelated to this change).