fix: create channel order only on confirm

[ovitrif]

Closes #738

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-android#1247

Design

N/A — no UI changes.

Preview

ios-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 modified in BitkitTests/TransferViewModelTests.swift:
  • Estimate refresh.
  • Unpaid order reuse.
  • Confirmation guards.
• Funding-address sizing is covered in BitkitTests/TransferViewModelHwTests.swift.
• Verification: build, 68 focused transfer tests, and SwiftFormat passed.
• Previous E2E: both transfers completed in staging; @transfer_1 then failed opening Settings behind the Background Payments sheet.
• Hardware journey: not run.