fix(dex): persist purchase orders before the swap and guard in-flight duplicates

[TaprootFreak]

What

Closes the broadcast-before-persist double-swap on the DEX liquidity-purchase path (part 2 of #4192; mirrors the payout fix from #4181).

Why

PurchaseStrategy.purchaseLiquidity() created the LiquidityOrder in memory, dispatched the swap (bookLiquiditySwap → dexService.swap) and only then saved the order for the first time. A crash in that window left no row at all; the upstream caller (e.g. a buy-crypto batch still in Created) re-issued the purchase and swapped a second time. Nothing in the DB prevented a duplicate purchase order either — the (context, correlationId) index is non-unique.

How

• Persist before the swap: the order row is written first and is the in-flight marker (txId IS NULL, isComplete = false).
• Partial unique index (migration): UNIQUE (context, "correlationId") WHERE "isComplete" = false AND "type" = 'Purchase' — a concurrent duplicate purchase for the same correlation now fails loudly at INSERT, before anything reaches the chain. Scoped deliberately: a Reservation may legitimately coexist in-flight with the same correlationId, and completed/cancelled rows (isComplete = true) keep historical duplicates out of the index. Production data was checked: exactly one in-flight row existed (no duplicates), so the index creation is safe.
• Broadcast boundary: EvmClient.doSwap wraps exactly the wallet.sendTransaction call (plus an empty-hash guard) in TxBroadcastError. The gas limit is estimated explicitly before the boundary (mirroring the existing sendNativeCoin/sendToken pattern) — estimation reverts, including the routine Uniswap slippage revert (Too little received), stay plain pre-broadcast errors. Because a direct provider.estimateGas revert surfaces the reason at e.reason (a send-time estimation historically nested it at e.error.reason), DexEvmService.swap now checks the whole reason chain, so the existing PriceSlippageException mapping and the retry self-healing keep working. All PurchaseStrategy chains are EVM-based and share this boundary.
• Error handling in purchaseLiquidity: a TxBroadcastError (or any error with a txId already assigned) keeps the row in-flight — the unique index then blocks blind re-purchases until an operator investigates. A plain pre-broadcast error cancels the row (removing it from the partial index) and rethrows, preserving today's retry-on-next-cron self-healing exactly.
• txId is persisted immediately after dispatch; target-amount estimation runs afterwards on purpose — if it fails, finalizePurchaseOrders still picks up the already-broadcast tx.
• Reader determinism: cancelled purchase attempts now remain persisted, so the single-row readers (fetchLiquidityTransactionResult, checkOrderReady, checkOrderCompletion) read the newest row per (context, correlationId) — a cancelled attempt can no longer shadow the live retry row.
• Escalation: stale in-flight purchase rows (older than 15 minutes, isComplete = false AND isReady = false — a ready order is progressing normally toward batch completion and is not stranded) trigger ONE monitoring mail with two labeled lists — rows without a txId (verify on-chain absence before cancelling) and rows that dispatched but never readied (reconcile manually; retries are blocked by the in-flight guard). No auto-cancel; the query skips eager relations.

Tests

• order persisted before the swap dispatch (call-order assertion)
• plain pre-broadcast error → order cancelled + saved, error rethrown
• TxBroadcastError → order stays in-flight (no cancel), error rethrown
• txId persisted right after a successful dispatch; estimation failure does not lose it
• escalation selects all stale in-flight purchase rows (type/isComplete/age), labels both classes and mails once
• swap boundary (evm-client.spec.ts): send failure / empty hash → TxBroadcastError; an estimateGas revert (the slippage shape) stays a plain error

[TaprootFreak]

Review protocol: 3 full review passes (conformity + logic lens each) until zero findings. Pass 1 surfaced a BLOCKER (the implicit gas estimation lived inside the broadcast boundary, so a slippage revert became a fail-closed TxBroadcastError and stuck the order in-flight) plus two MAJORs (persisted cancel rows shadowed the live retry row in the single-row readers; the stranded alert missed dispatched-but-uncompleted rows). Pass 2 caught that moving the estimation before the boundary changed the ethers error shape and broke the downstream slippage check (verified against the vendored ethers source) and that the alert now over-flagged healthy slow buys. Fixed by walking the full revert-reason chain and filtering the alert to not-yet-ready orders, with a dedicated dex-evm.service slippage-mapping spec. Pass 3: clean on both lenses.