feat(gui): Approve dialog before publishing Bitcoin lock transaction

[binarybaron]

This diff introduces a new "approvals" mechanism that alters the swap flow by requiring explicit user intervention before the Bitcoin lock transaction is broadcast. Previously, the Bitcoin lock was executed automatically without any user prompt. Now, the backend defines ApprovalRequestType (e.g. a PreBtcLock variant with details like btc_lock_amount, btc_network_fee, and xmr_receive_amount) and ApprovalEvent (with statuses such as Pending, Resolved, and Rejected). The method request_approval() in the TauriHandle struct uses a oneshot channel and concurrent timeout handling via tokio::select! to wait for the user's decision. Based on the outcome—explicit approval or timeout/rejection—the approval event is emitted through the emit_approval() helper, thereby gating the subsequent broadcast of the Bitcoin lock transaction.

On the UI side, changes have been made to reflect the new flow; the modal (for example, in SwapSetupInflightPage.tsx) now displays the swap details along with explicit action buttons that call resolveApproval() via RPC when clicked. The Redux store, selectors, and hooks like usePendingPreBtcLockApproval() have been updated to track and display these approval events. As a result, the overall functionality now requires the user to explicitly approve the swap offer before proceeding, ensuring they are aware of the swap's key parameters and that the locking of funds occurs only after their confirmation.

OfferAcceptFlow.mov

[Einliterflasche]

this one is forked off asb/cache-quotes i think, we should rebase before merging

[binarybaron]

this one is forked off asb/cache-quotes i think, we should rebase before merging

will do but let's merge #288 first. I don't want to deal with merge conflicts.

[binarybaron]

@Einliterflasche @b-enedict @delta1 This is ready for review. I think the changes are mostly fine. Unless there any objections I'm going to merge this.