feat: preserve transaction status (mempool/IS-locked/confirmed/chain-locked) in TransactionRecord

[lklimek]

User Story

As a wallet application developer, I want TransactionRecord to carry the transaction's lifecycle status (mempool → IS-locked → confirmed → chain-locked) so that I can display meaningful status indicators to users without re-deriving state from height/block_hash fields.

Problem

TransactionContext already distinguishes Mempool, InBlock, and InChainLockedBlock — but record_transaction() in ManagedAccount discards the variant after extracting height/block_hash:

// managed_account/mod.rs:385-390
let tx_record = TransactionRecord {
    height: context.block_height(),      // Some(h) or None
    block_hash: context.block_hash(),    // Some(hash) or None
    // TransactionContext variant is lost here
    ...
};

Consumers (like dash-evo-tool) can only infer height.is_some() → confirmed vs unconfirmed, losing the richer status information that was available at recording time.

Requested Changes

1. Add status field to TransactionRecord

pub struct TransactionRecord {
    // ... existing fields ...
    /// Transaction lifecycle status
    pub status: TransactionContext,
}

Preserve the TransactionContext that's already passed to record_transaction().

2. Set Utxo.is_instantlocked on InstantSend lock receipt

The is_instantlocked field exists on Utxo and is used in coin selection (is_spendable(), coin_selection.rs), but is never set to true — it's initialized as false in Utxo::new() and no code path flips it.

When SyncEvent::InstantLockReceived fires, UTXOs belonging to the locked transaction should be updated.

3. Add status to WalletEvent::TransactionReceived

WalletEvent::TransactionReceived {
    // ... existing fields ...
    status: TransactionContext,
}

So consumers know if a received transaction is mempool/confirmed/chain-locked without re-querying the wallet.

4. (Nice to have) Add WalletEvent::TransactionStatusChanged

WalletEvent::TransactionStatusChanged {
    wallet_id: WalletId,
    txid: Txid,
    old_status: TransactionContext,
    new_status: TransactionContext,
}

Fires on status transitions (Mempool → IS-locked → Confirmed → ChainLocked), enabling reactive UI updates.

Context

dash-evo-tool PR dashpay/dash-evo-tool#776 integrates the MempoolManager with BloomFilter strategy. With mempool tracking active, the wallet now sees unconfirmed transactions — but we cannot distinguish them from IS-locked transactions in the UI because the status information is discarded upstream.

We're adding a TransactionStatus enum on the evo-tool side and inferring what we can from height, but full lifecycle tracking requires these upstream changes.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[xdustinface]

1. Add status field to TransactionRecord

This might be good yeah will have a look.

2. Set Utxo.is_instantlocked on InstantSend lock receipt

This is already implemented in #552 (so included in #558) unless i get the request wrong.

3. Add status to WalletEvent::TransactionReceived

This is already implemented in #552 (so included in #558) unless i get the request wrong.

4. (Nice to have) Add WalletEvent::TransactionStatusChanged

This is already implemented in #552 (so included in #558) unless i get the request wrong.

---

As for the "confirmed -> chainlock" transition, this is not happening at the moment. I initially had this transition also implemented in the TransactionStatusChanged but then there are this weird cases that retroactively after a fresh sync all transactions even deeply buried ones would be marked chainlocked and thousands of chainlock events would fire for medium/large wallets. Sure, this could be reduced to send only the recent ones but then thats also inconsistent then. So at the end i decided against it for now since chainlocks are not really a transaction property anyway and they can be tracked via SyncEvent::ChainLockReceived and then transctions can be marked. But i will have some more thoughts about it and im open for other opinions/suggestions about it.