fix: create order only on swipe

[ovitrif]

Closes #1243

Description

This PR moves Blocktank channel-order creation to the final confirmation step of a transfer from savings to spending.

Previously, pressing Continue on Spending Amount or Advanced created an order before the user committed to the transfer. Going back, changing the amount or receiving capacity, and continuing again could create more orders that were left unpaid.

The transfer flow now works as follows:

• Spending Amount and Advanced request fee estimates for the selected amount and receiving capacity when the user continues.
• Use Defaults restores the default receiving capacity and refreshes its fee estimate.
• For software wallets, swiping to confirm creates the order and funds it.
• For hardware wallets, starting the signing flow from Hardware Sign creates the order before requesting approval on the Trezor.
• If funding fails after an order has been created, retrying the same transfer reuses that unpaid order.
• Changing the transfer amount or receiving capacity clears the retained order; the next confirmation creates an order for the new selection.
• Back navigation and changes to the transfer are disabled while order creation or funding is in progress, so the selected transfer stays consistent through confirmation.

Fee estimation and order creation use the same backend fee-calculation path. Differences between the fee shown at confirmation and the fee ultimately paid were already possible in the existing flow. This PR preserves that fee behavior and focuses on when the order is created; adding a fee-mismatch guard would be a separate behavior change.

Counterpart: synonymdev/bitkit-ios#741

Design

N/A — no UI changes.

Preview

android-transfer-preview.mp4

QA Notes

Manual Tests

• 1. Spending Amount → Continue → back → Continue: estimates refresh until confirmation creates one order.
• 2. Spending Confirm → Advanced → change capacity → Continue → Use Default: fees follow the selected capacity.
• 3. Funding fails → retry confirmation: reuses the unpaid order.
• 4. Confirm → attempt back during order creation or payment: the transfer stays locked until completion.
• 5. Hardware Sign → Open Trezor Connect → approve: creates one order and completes the transfer.

Automated Checks

• Unit tests added: confirmation blocks transfer changes in TransferViewModelTest.kt.
• Unit tests modified in TransferViewModelTest.kt:
  • Estimate refresh.
  • Unpaid order reuse.
  • Native SegWit fee sizing.
• Verification: build and 2,455 unit tests passed.
• Lint: changed files are clean.
• Previous E2E: staging @transfer_1 passed for default and custom capacity.
• Hardware journey: not run.