fix: delete data down to the remaining watermark on reorg

[cdsiren]

fix: delete data down to the remaining watermark on reorg

Problem

A reorg can permanently wedge a single integration. It stops converging and logs this
forever, ~26 retries/sec, until someone deletes rows by hand:

msg=converge-retry ig=uniswap_v3_swap msg=inserting data: inserting blocks:
ERROR: duplicate key value violates unique constraint "u_evm_uniswap_v3_swap" (SQLSTATE 23505)

Sibling integrations on the same source keep converging, so it reads as a
single-integration failure rather than a reorg. Restarting does not help, because the
conflicting rows are already committed.

Cause

Task.update writes one shovel.task_updates row per converge batch, with num set
to the batch's last block (task.go:443). One update therefore covers the whole range
(previous update, num].

Task.Delete(n) removes updates at num >= n but tells the destination to delete at
block_num >= n. When the batch spans more than one block, the blocks below n in that
same batch keep their data while the watermark rewinds below them — they are the batch's
canonical prefix, not orphaned-chain data, since only n and above were reorged out.

Converge then resumes from the highest remaining update and re-requests those blocks.
dig.Integration.Insert uses CopyFrom, which cannot express on conflict, so the insert
hits u_<table> and rolls back. Every subsequent poll repeats it.

The window is batchSize > 1, which is the normal case: with a 2-block batch it is roughly
a coin flip per reorg. Concretely, from a production instance on mainnet:

watermark (task_updates.num)   25666514
orphan rows in evm_uniswap_v3_swap   2, at blocks 25666516 and 25666517

The update at 25666518 was deleted along with data >= 25666518; blocks 25666516–17 from
that same batch survived below the rewound watermark. Deleting exactly those two rows
unwedged the integration with no restart, and Shovel re-inserted them byte-identically
(md5 of every re-inserted row matched the pre-delete capture), which confirms they were
canonical rather than reorged data.

Fix

Task.Delete now asks where Converge will actually resume — one past the highest
remaining update — and deletes destination data from there, so no block is ever left
without an update covering it. The new resume value is never greater than n (no update
at or above n survives the delete), so this only ever widens the delete, and only within
a batch that was already being discarded.

With no updates left, the task restarts at its configured start, or at the chain head when
there is none; both are above anything already stored, so that case falls back to n
rather than deleting the destination's whole history.

Re-indexing a batch's earlier blocks is the same work the task was already about to do —
it re-requests that range from the node either way.

Tests

• TestConverge_ReorgBatchPrefix (new): one update covering blocks 1–2, block 2 reorged
  out, asserts the task converges to the canonical chain. Without the task.go change it
  fails with inserting data: inserting blocks: duplicate key: 1 — the same shape as the
  production error above.
• testDestination was too permissive to catch this and needed two fixes to match
  dig.Integration: Delete now deletes at >= n rather than the single key n, and
  Insert reports a duplicate instead of silently overwriting, since the real destination
  copies into a table with a unique index and no on conflict. The existing
  TestConverge_Reorg passes under both, because it writes one update per block, so
  batch-granularity never comes into play.
• Full suite green (go test -p 1 ./..., postgres 15 via pqxtest).

Alternatives considered

• One task_updates row per block. Removes the granularity mismatch at its root, but
  multiplies watermark writes by the batch size.
• on conflict do nothing on insert. Not expressible through CopyFrom, and it would
  mask genuine duplicates.