ENG-296: Align ETH-USDT Cash Wallet receive path

[forge0x]

Rebuilt on current feature/bridge-integration after ENG-394 landed.

ENG-296 is now narrowed to ETH-USDT Cash Wallet receive-path alignment. Wallet creation/defaulting is already handled by ENG-394, and Bridge virtual-account creation/query behavior is intentionally left to the dedicated Bridge VA tickets.

Changes:

• Accept IBEX crypto.receive webhooks for Ethereum USDT (currency=USDT, network=ethereum)
• Normalize persisted receive metadata to USDT / ethereum
• Reject stale Tron USDT payloads on this ETH-USDT Cash Wallet path
• Add focused unit coverage for Ethereum USDT receive handling

Tests:

• PASS: LOGLEVEL=warn ../../node_modules/.bin/jest --config ./test/flash/unit/jest.config.js --bail --verbose test/flash/unit/services/ibex/webhook-server/routes/crypto-receive.spec.ts
• PASS: git diff --check
• NOTE: full tsc --noEmit -p tsconfig.d.json && tsc --noEmit still fails on inherited baseline test/legacy-integration type errors unrelated to this PR.

[linear]

ENG-296

[patoo0x]

I created a Flash engineering review artifact for this PR.

Full rendered artifact: https://htmlpreview.github.io/?https://github.com/lnflash/flash/blob/patoo0x/pr-344-review-artifact/docs/artifacts/pr-344/eth-usdt-cash-wallet-review.html
Source file: https://github.com/lnflash/flash/blob/patoo0x/pr-344-review-artifact/docs/artifacts/pr-344/eth-usdt-cash-wallet-review.html

Quick review takeaway: good direction, but I would not merge until the migration/address-ownership questions are closed.

Critical / high-risk items to verify:

• Existing bridgeEthereumAddress values can bypass new IBEX receive-info creation. Can we prove every existing address is tied to the correct ETH-USDT IBEX wallet, or do we need a migration/backfill?
• ensureEthUsdtCashWallet(account) runs before the existing-VA idempotency guard. Is it intentional to promote the USDT wallet to default even when a Bridge VA already exists?
• Ibex.getAccountDetails(walletId, currency) converts balances based on caller-provided currency. Are all callsites audited so we do not create wrong-unit balance reads?
• Webhook now accepts USDT + ethereum and rejects Tron. Confirm upstream payloads and existing customer deposit instructions are fully cut over.
• Withdrawal idempotency is improved, but concurrent retries still need DB-level uniqueness/transactional protection against duplicate pending rows.
• PR body says tests/build passed, but GitHub shows Checks (0), so CI/build evidence should be attached or run before merge.

Note: I could not enable GitHub Pages on lnflash/flash from this account; repository settings show no Pages/options access. The rendered link above uses the uploaded GitHub branch file via htmlpreview as an interim full-artifact view.

[forge0x]

Closing this draft because ENG-296 is now marked duplicate/covered by ENG-276. Dread confirmed with Olaniran that ENG-276 includes the IBEX crypto receive webhook path, so we should keep this webhook/reconciliation surface owned by ENG-276 instead of landing a separate PR.