ComputeExtendedSketch builds the extension from the live short-id mapping instead of the snapshot

This description is AI generated, mistakes can be made.

Intent: Extended sketches (responder's REQSKETCHEXT reply and the initiator's local extended sketch) should cover the snapshotted set. The live mapping holds only txs added after the snapshot, usually none, so every extension describes the wrong set and reconciliation degrades to flooding or wrong diffs.

Behaviour change: Original: the extension sketch encodes the same elements as the initial sketch. Mutant: it encodes only txs added since the snapshot, so the higher elements are inconsistent with the lower ones. Peers fail to decode or decode garbage short ids, and every extended round ends with full announcement.

Trigger: An inbound Erlay peer sends REQTXRCNCL, gets our sketch, then sends REQSKETCHEXT. We answer with the higher half of a sketch over m_short_id_mapping, which is empty unless new txs arrived. The initiator path behaves the same way when we receive an extension.

Spec violation: BIP-330: the sketch extension must be computed over the same set as the initial sketch, so that the combined 2x-capacity sketch is valid.

Severity if undetected: medium

Why tests miss it: RemoveFromSetsKeepsExtensionConsistentTest compares two rounds' extensions for equality (both become the empty-set sketch under the mutant), HandleReconcilDiffBoundsShortIDsTest and ShouldRespondToReconciliationRequestTest only check that a reply is produced; functional tests have no extension cases

Plausibility: The class has paired m_short_id_mapping / m_short_id_mapping_snapshot members, and dropping the suffix is a one-token slip in a function whose comment only says 'we don't have to recompute short IDs here'.

Equivalence risk: Equivalent only if the live mapping happens to equal the snapshot, which never holds because SnapshotLocalSet clears the live mapping.