Multisig SendEnd is not retry-safe when the transaction is already on-chain

[dcorral]

Completing an approved multisig operation unconditionally finalizes the combined PSBT before executing (handle_operation, OperationStatus::Approved branch). If the operation's transaction is already broadcast, because another cosigner finalized and broadcast it or this party did but lost its local state, a party whose collected response PSBTs don't reach threshold signatures fails with CannotFinalizePsbt on every sync_with_hub retry, even though the transaction is already confirmed on-chain and visible in the party's own BDK graph. Since operations are processed sequentially, the stuck operation also blocks every later operation for that party, permanently.

A response can end up under-signed because neither the client nor the hub verifies that an ack's response PSBT contains the responder's signature (only psbt_signature_count > 0 is checked), so the hub can approve an operation whose combined files can never finalize.

[dcorral]

Proposed fix is an already-broadcast check in the Approved branch before finalizing:

• operation tx known to the wallet's BDK graph, or confirmed per an indexer probe as authoritative fallback -> complete the operation without re-finalizing the combined PSBT.
• get_transfer_end_data derives the txid from psbt.unsigned_tx instead of extract_tx, so the completion path can run on a combined-but-not-finalized PSBT
• tx not broadcast anywhere -> behavior unchanged, the PSBT must finalize or the operation errors as today (fail closed)

This was already implemented in the UTEXO fork (UTEXO-Protocol#46)

[nicbus]

Thanks for the PR.

This issue falls into a wider fix bucket we've already scheduled: every hub operation should have a deterministic outcome which is the same for all cosigners. E.g., in addition to this, the outcome should not depend on proxy data as it can be wiped, causing inconsistencies between cosigners.

We'll tackle that as a whole, this PR can remain open as a reminder.