fix(sdk-core): add EVM staking types to TSS signing bypass list

[mrdanish26]

TICKET: WAL-756

Summary

1. WAL-756 — BNB/BSC staking broken
Staking wallets call signTransaction without txParams. After WAL-375, resolveEffectiveTxParams() throws InvalidTransactionError because effectiveTxParams.type is undefined and staking intentType strings were not in NO_RECIPIENT_TX_TYPES.

2. XDC/BSC token enable/approve
Coin-specific verifyTssTransaction overrides in xdcToken.ts, bscToken.ts, xdc.ts, bsc.ts, and evmCoin.ts had stale hardcoded bypass lists and never updated. When the parent class added tokenApproval, enableToken, bridgeFunds, etc., these overrides were left behind — causing "missing txParams" errors on app.bitgo-test.com when enabling tokens on XDC.

Solution

Staking fix (recipientUtils.ts):

• Detect staking intents generically via stakingRequestId presence on
  the intent (a required field on BaseStakeIntent in @bitgo/public-types)
  rather than enumerating staking intentType strings that drift over time
• Add intent.intentType fallback so txType propagates to downstream
  verifyTssTransaction callers when txParams.type is absent

Centralization (all coin modules):

• Export NO_RECIPIENT_TX_TYPES from sdk-core public API (tss/index.ts)
  as the single source of truth
• Replace all stale inline bypass arrays with NO_RECIPIENT_TX_TYPES.has()
  in: abstractEthLikeNewCoins.ts, bsc.ts, bscToken.ts, xdc.ts,
  xdcToken.ts, evmCoin.ts
• Existing verifyTssTransaction overrides preserved

Testing

• Unit tests updated
• staking-bnb-hot E2E test in bitgo-retail passes after SDK bump

[lokesh-bitgo]

@claude Please do a thorough review of this PR.

Focus especially on:

• any bugs or incorrect logic in the changes
• whether these changes could impact existing flows or cause regressions
• whether the implementation is aligned with the requirement/design
• whether the changes are correct and complete
• missing edge cases, validation gaps, and test coverage gaps

Please call out concrete issues clearly and separate them by severity if possible.

[ashutoshkumar-6]

Overall the direction of centralizing NO_RECIPIENT_TX_TYPES and the staking detection via stakingRequestId is good. However, there is a critical gap: the fix in resolveEffectiveTxParams prevents InvalidTransactionError from throwing, but the downstream verifyTssTransaction guards in every affected coin (bsc.ts, bscToken.ts, xdc.ts, xdcToken.ts, evmCoin.ts, and the parent abstractEthLikeNewCoins.ts) will still throw 'missing txParams' for staking types — see inline comments for details.

[ashutoshkumar-6]

[Critical] This fix prevents InvalidTransactionError here, but the staking bypass does not propagate to verifyTssTransaction.

The full call chain after this function returns for a staking intent (stakingRequestId present, no recipients) is:

resolveEffectiveTxParams returns { type: 'delegate' }  ← fixed here
  → baseCoin.verifyTransaction({ txParams: { type: 'delegate' } })
  → verifyTssTransaction: !txParams?.recipients && !NO_RECIPIENT_TX_TYPES.has('delegate')
  → throws 'missing txParams'  ← NOT fixed

'delegate', 'undelegate', 'stake', 'unstake' are not in NO_RECIPIENT_TX_TYPES, so every verifyTssTransaction override (bsc.ts:79, bscToken.ts:57, xdc.ts:79, xdcToken.ts:81, evmCoin.ts:119, abstractEthLikeNewCoins.ts:3112) will still throw for BSC staking.

The fix moves the error from InvalidTransactionError (here) to Error('missing txParams') (in verifyTssTransaction) but does not eliminate it. The staking flow remains broken end-to-end.

[ashutoshkumar-6]

[Critical] This guard still throws for BSC staking transactions.

After resolveEffectiveTxParams returns effectiveTxParams = { type: 'delegate' } (no recipients), this evaluates as:

• !txParams?.recipients → true
• txParams.prebuildTx?.consolidateId → undefined (no prebuildTx on staking tx)
• NO_RECIPIENT_TX_TYPES.has('delegate') → false
• Result: throws 'missing txParams'

The staking types propagated via intent.intentType are not in NO_RECIPIENT_TX_TYPES. Same issue exists in bscToken.ts, xdc.ts, xdcToken.ts, and evmCoin.ts:119.

Possible fixes:

1. Check for a staking signal here too (e.g. set a flag on effectiveTxParams like effectiveTxParams.isStakingIntent = true in resolveEffectiveTxParams, then check it here), or
2. Pass staking types through NO_RECIPIENT_TX_TYPES with a comment, or
3. Remove this override entirely and let the parent handle it (as the commit message 467ff30d says was intended — but the override is still present in the PR)

[ashutoshkumar-6]

[Critical] Same issue as in bsc.ts: NO_RECIPIENT_TX_TYPES does not contain staking types (delegate, undelegate, stake, unstake, etc.). When a staking transaction arrives here with txParams = { type: 'delegate' } (returned by resolveEffectiveTxParams), this check throws 'missing txParams'.

Note that this parent class is also what bsc.ts would fall through to if the override were removed (as the commit message for 467ff30d states). Either way, the staking bypass needs to be present at this layer too.

[mohammadalfaiyazbitgo]

@mrdanish26 let's also add the stakingRequestId, it should be in the prebuildTx object. @noel-bitgo if you can confirm.

[ashutoshkumar-6]

[High] as any cast is unsafe. PopulatedIntent in baseTypes.ts does not define stakingRequestId, so TypeScript cannot verify this field exists at compile time. If BaseStakeIntent in @bitgo/public-types renames or removes stakingRequestId, this silently returns false at runtime with no compile-time error.

Consider importing BaseStakeIntent from @bitgo/public-types and writing a proper type guard:

function isBaseStakeIntent(intent: unknown): intent is BaseStakeIntent {
  return typeof (intent as any)?.stakingRequestId === 'string';
}
const isStakingIntent = isBaseStakeIntent(txRequest.intent);

Or extend the PopulatedIntent union in baseTypes.ts to include a staking variant.