Clear() drops the EXT_REQUESTED exception and wipes txs the initiator gathered during an extension round

This description is AI generated, mistakes can be made.

Intent: After an initiator extension round, the local set holds txs that arrived after the snapshot and were never sketched. Clearing them means those txs are never announced to that peer, through reconciliation or fanout.

Behaviour change: Original: txs added to the peer's set between our REQSKETCHEXT and the extension SKETCH stay for the next round. Mutant: they are discarded and never relayed to that peer.

Trigger: We are the initiator with an outbound recon peer. The initial sketch fails to decode (EXT_REQUESTED), a new mempool tx is added to that peer's set (AddToSet), and the peer's extension SKETCH arrives, so HandleSketchExtension calls Clear(). At the next REQTXRCNCL our set size is 0 and the tx is not offered.

Spec violation: Documented in Clear(): 'If we are in the middle of an extension phase, we want to keep the data stored in the local set for the next round, as this contains transactions that have been received while reconciling'.

Severity if undetected: medium

Why tests miss it: p2p_txrecon_responder.py interleaved test covers only the responder (m_we_initiate=false). p2p_txrecon_initiator.py interleaved test covers INIT_REQUESTED only. No unit test reaches HandleSketchExtension

Plausibility: It reads as a simplification ('the initiator always clears its set after a round'), and the phase exception is easy to see as redundant because the snapshot already holds the sketched txs.

Equivalence risk: Only Clear() calls with m_we_initiate && phase==EXT_REQUESTED differ, i.e. the end of an initiator extension round. That path is reachable, and it is observable whenever a tx arrived during it.