Describe the feature

we currently trigger poolupdates in two places:

Place 1: Basefee/Blobfee-triggered updates (lines 580-580)

        // update block info
        let block_hash = block_info.last_seen_block_hash;
        self.set_block_info(block_info);

This calls set_block_info() which internally calls:

• update_basefee() → can trigger promotions from BaseFee pool to Pending when basefee decreases
• update_blob_fee() → can trigger promotions/demotions for blob transactions

Place 2: Account/sender-triggered updates (lines 593-593)

        // Update removed transactions metric
        self.metrics.removed_transactions.increment(removed_txs_count);

        let UpdateOutcome { promoted, discarded } = self.update_accounts(changed_senders);

This calls update_accounts() which:

• Processes sender balance/nonce changes
• Triggers sub-pool updates based on account state changes

The Problem
Both places can update the same transactions independently:

1. Basefee decrease → promotes transactions from BaseFee → Pending via enforce_basefee_with()
2. Sender changes → same transactions might get updated again via update_accounts()

This creates overlapping/duplicate tracking in the promoted and discarded outcome sets, leading to inaccurate metrics and potential inconsistent pool state.

where a lower basefee can trigger a promotion:

which we currently dont track properly and only via the changed accounts:

the problem here is that these can overlap

e.g. promoted basefee txs can also appear in either promoted or discarded

a potential fix here is
before updating the basefee internally, use the new basefee to iterate over the changed senders

Additional context

No response