fix(tss): verify recipients before signing

[mrdanish26]

TICKET: WAL-375

Description

Ensures verifyTransaction always receives recipient details before any signing material is sent to BitGo, preventing a compromised API from silently substituting signableHex with attacker-controlled bytes.

A resolveEffectiveTxParams() guard is added to both ECDSA and MPCv2 signRequestBase() paths. It resolves recipients from three sources in priority order:

1. txParams.recipients — normal case.
2. txRequest.intent.recipients — fallback for smart-contract interactions (e.g. Tempo supplyController) where native ETH amount = 0 so buildParams is empty but intent carries the recipients.
3. NO_RECIPIENT_TX_TYPES exemption — types that legitimately carry no recipients; verifyTransaction handles validation internally for these. Throws InvalidTransactionError if none of the above apply.

A database query against marts.wallet_platform.bitgo2__transaction_request identified all intent types where INTENT:recipients IS NULL OR ARRAY_SIZE(INTENT:recipients) = 0. Two ECDSA-path types with significant
record counts were missing from the exemption list:

• enableToken (17,765 records) — TSS wallets call buildTokenEnablements() which does not populate buildParams.recipients
• customTx (7,082 records) — DeFi/WalletConnect smart contract interactions; already exempted at populateIntent() server-side but inconsistently enforced at signing

Both have been added to NO_RECIPIENT_TX_TYPES and the abstractEthLikeNewCoins.ts bypass list.

NO_RECIPIENT_TX_TYPES (8 types)

Type	Reason
acceleration, fillNonce, transferToken, tokenApproval, consolidate, bridgeFunds	Pre-existing exemptions
enableToken	TSS wallets do not populate recipients for token enablement — confirmed via prod DB
customTx	DeFi/WalletConnect smart contract interactions — already exempted at populateIntent() server-side; must be consistent at signing

Both recipientUtils.ts and the inline bypass list in abstractEthLikeNewCoins.ts verifyTssTransaction are kept in sync.

A previous PR (#8462) hard-threw on any empty recipients, breaking cases 2 and 3. It was reverted in #8538. This PR supersedes it.

Testing

New unit tests — tss/recipientUtils.ts (16 tests):

• All 8 exempt types pass without recipients
• txParams.recipients takes priority over intent
• Intent fallback when txParams is empty or undefined
• Throws for non-exempt types with no recipients

Updated integration tests — ecdsaMPCv2/signTxRequest.ts (13 tests):

• Replaced 4 false-confidence .should.not.be.rejectedWith() assertions with nock-backed isDone() assertions that prove signing completes end-to-end
• Added acceptance tests for enableToken and customTx exemptions
• Existing reject tests unchanged

[linear]

WAL-375 [Security] MPCv2 signTxRequest() Defaults txParams to Empty Recipients — Transaction Verification Bypass

[sachushaji]

@claude