Send-max computed at the default fee speed, but the drain happens at the selected speed

[coreyphillips]

Severity: Medium (wrong amount sent)

getMaxSendAmount computes the max sendable amount using the fee estimate for the default transaction speed (DeriveBalanceStateUseCase.kt:214-228). At confirm time, sendOnchain infers "is max" by equality against that cached value (amount == maxSendOnchainSats, AppViewModel.kt:2887-2888) while the actual send runs at the user-selected speed (_sendUiState.value.speed, AppViewModel.kt:2885). When the two speeds differ, sendAllToAddress drains at a fee rate the displayed amount never accounted for, so the send either fails or delivers a different amount than the user confirmed.

iOS handles this correctly: shouldUseMaxOnchainSend recomputes the max against the currently selected fee rate at confirm time and degrades to an exact-amount send if the cached max is stale (SendConfirmationView.swift:697-712).

Steps to reproduce:

1. Leave the default transaction speed on Normal.
2. Start an on-chain send using the max amount.
3. On the confirm screen, switch the fee speed to Fast (or Slow).
4. The equality check still matches the cached max, so the wallet drains via sendAllToAddress at the newly selected rate; the delivered amount differs from what was displayed, or the send errors.

Suggested fix: mirror iOS, recompute the max sendable amount at confirm time with the selected fee rate, or record the fee rate used for the cached max and only treat equality as drain-mode when the selected rate matches it.