fix(pxe): widen tracked sender tagging ranges with onchain discovery evidence

[vezenovm]

Stacked on #24655. Found while reviewing #24655. This is the "Window straddle" residual edge flagged in https://gist.github.com/nventuro/0aa690736b1d2865e27197723a814e9d (latent regardless of reverts); the fix takes the gist's suggested "extend an entry monotonically" option.

#24655 made discovery skip a differing range for an already tracked (secret, txHash) pair instead of throwing.
Before #24655 this same scenario hit the "Conflicting range" throw and permanently wedged the secret, so it was broken either way.

Fix: replace skipExisting with mergeExisting. On a range mismatch, discovery widens the stored entry to the union of both ranges (grow-only, driven by onchain evidence). The partial revert case is unchanged: the discovered sub-range unions to the existing prove-time entry, and the finalized receipt step still resolves it. The prove-time persist path keeps the strict conflict throw.

Red-green:

• "widens a tracked pending range when discovery evidences further indexes for the same tx" fails on the base branch with lastUsed 10 instead of 11, and passes with the merge.
• "assembles a pending range piecewise when a tx straddles the sync window boundary" drives the actual window-advance loop: a tx with tags on both sides of the window boundary gets stored as [83, 83] by window 1 and widened by window 2. It throws "Conflicting range existing [83, 83] vs new [84, 84]" on fairies-v5, under-reports lastUsed as 83 on the base branch, and passes with the merge (including a follow-up sync that finalizes the widened entry cleanly).

Store-level tests pin the union semantics: a sub-range keeps the entry, a range beyond it widens it, an untracked tx still stores.