fix(sdk-core): wire resolveEffectiveTxParams into EddsaMPCv2Utils (WCI-1111)

[bitgo-ai-agent-dev]

What

• eddsaMPCv2.ts signRequestBase: replaced the vulnerable params.txParams || { recipients: [] } fallback with resolveEffectiveTxParams(txRequest, params.txParams, this.baseCoin.getChain()). The function throws InvalidTransactionError when recipients cannot be resolved and the intent is not a recognised no-recipient type.
• wallet.ts signTransactionTss: removed the EdDSA MPCv2 special-case block that pre-fetched the txRequest and called txParamsFromIntent before handing off to signTxRequest. That pre-fetch was introduced to work around the missing guard; now that resolveEffectiveTxParams owns intent-based derivation inside signRequestBase (which already fetches the txRequest internally when given a string ID), the wallet-layer duplication is redundant. Removed the now-unused txParamsFromIntent import.
• Tests: added resolveEffectiveTxParams guard suite to signTxRequest.ts covering:
  • stakingAuthorize attack vector (no txParams, non-allowlisted intent → throws)
  • Empty-recipient txParams with non-allowlisted intent → throws
  • Allowlisted deactivate intentType with no txParams → succeeds
  • Allowlisted consolidate intentType with no txParams → succeeds
  • Intent-sourced recipients when txParams absent → succeeds
  • Staking intent with stakingRequestId signal → succeeds

Why

Trail of Bits finding TOB-BITGOEDMPC-1 (WCI-1100): the EdDSA MPCv2 re-sign path silently substituted an empty-recipients object when txParams was absent. Several coin-level verifyTransaction implementations (SOL, VET, Tempo, TRON) skip output-matching validation when recipients.length === 0, allowing a compromised BitGo server to present a malicious txHex that signs without any client-side validation.

ECDSA already used resolveEffectiveTxParams for fail-closed behaviour (ecdsaMPCv2.ts:958,965 and ecdsa.ts:821,828). This PR ports the same pattern to EdDSA MPCv2. MPCv1 (eddsa.ts) is explicitly out of scope per the ticket.

Depends on WCI-1110 (base branch wci-1110-fix-resolve-effective-tx-params-sol), which fixes resolveEffectiveTxParams to preserve tokenName for SOL token transfers and adds the deactivate/delegate/closeAssociatedTokenAccount allowlist entries needed by EdDSA coins.

Test plan

• signTxRequest throws InvalidTransactionError for stakingAuthorize intent with no recipients and no txParams
• signTxRequest throws for empty txParams.recipients with non-allowlisted intent
• signTxRequest succeeds for deactivate and consolidate (allowlisted no-recipient intents)
• signTxRequest succeeds when intent provides recipients and txParams is absent
• signTxRequest succeeds for staking intents with stakingRequestId
• Existing signing tests pass (user key, backup key, message signing, 429 retry)

Ticket: WCI-1111

[linear-code]

WCI-1111

[abhijit0943]

Requesting changes specifically on the bare 'authorize' allowlist entry in NO_RECIPIENT_TX_TYPES.

The EdDSA resolveEffectiveTxParams wiring looks correct for WCI-1111.

[Marzooqa]

Requesting changes specifically on the bare 'authorize' allowlist entry in NO_RECIPIENT_TX_TYPES.

The EdDSA resolveEffectiveTxParams wiring looks correct for WCI-1111.

Removing 'authorize' from the allowlist actively breaks the signing flow. Adding coin-layer validation in verifyTransaction isn't straightforward either — the meaningful check (newWithdrawPublicKey) requires intent fields that aren't currently threaded through to that layer, so any check added today would silently no-op in the real flow. Properly fixing this needs scoping and testing.

[abhijit0943]

Discussed offline - Approving.

Agree with keeping authorize on the no-recipient allowlist for now so we don't break that signing path in this PR. That matches current behavior; proper intent-field validation for authorize belongs in a follow-up (coin-layer verifyTransaction), as noted in WCI-1110 / discussion here.

Please open a follow-up ticket for that and link it on this PR before merge if possible. The EdDSA resolveEffectiveTxParams wiring LGTM for WCI-1111.

[Marzooqa]

Please open a follow-up ticket for that and link it on this PR before merge if possible.

Ticket -> WCI-1243