Adds send and broadcast support to the demo wallet

[Johnosezele]

Adds a full send flow to the demo wallet. The /send route now presents a validated single recipient form, loads fee-rate suggestions from the active wallet network without blocking the UI isolate, supports sats and BTC amount entry, and requires confirmation before signing and broadcasting.

Notes to Reviewers

• Fee suggestions run through an injectable isolate job runner so slow backend calls do not freeze Send navigation.
• The transaction build/broadcast boundary remains sats-based even when the UI displays BTC, because WalletService.buildTransaction take integer satoshis (Amount.fromSat) and floating point BTC in the service layer would invite rounding errors, the UI converts once at submit time and the confirmation dialog shows both units so the user can verify the exact spend.

[reez]

After a successful broadcast I think we should apply the transaction to the wallet as unconfirmed and persist those staged changes before returning. TxBuilder.finish() only stages/persists the change address reservation; it does not record this spend in the wallet graph. Without wallet.applyUnconfirmedTxs([...]) plus persistence, the UI can keep showing the spent UTXO as available and a second send before sync can reuse it.

[Johnosezele]

Thanks for catching this. I've updated the broadcast path to apply the extracted transaction as unconfirmed after a successful broadcast, then persist the staged wallet changes before returning... that should keep the local wallet graph from treating the spent UTXO as available while we wait for the next sync.