test(hbar): add unit tests for CoinTransferBuilder self-transfer

[Doddanna17]

Summary

• Adds unit tests for CoinTransferBuilder self-transfer (sender == recipient), covering the stakeClaimRewards 1-tinybar claim-rewards mechanism
• Verifies two separate accountAmounts entries are preserved in the protobuf (bypassing Hedera SDK same-account netting)
• Covers serialisation round-trip and signing

Test plan

• yarn mocha --grep "HBAR CoinTransferBuilder" passes all 4 test cases in coinTransferBuilder.ts
• CI unit test suite passes for sdk-coin-hbar

Ticket: SI-539

[linear-code]

SI-539

[Doddanna17]

HBAR Claim Rewards — Self-Transfer Implementation Notes

Background

Hedera has no dedicated "claim rewards" transaction type at the protocol level. Staking rewards are harvested automatically whenever a CryptoTransfer touches the account. The standard approach is a 1-tinybar self-transfer (sender == recipient == accountId), which atomically flushes pending_reward into the account balance.

Data flow

staking-service
  HbarClaimRewardsRequestStrategy → amount = 1 tinybar, self-transfer intent

bitgo-microservices (hbar.ts — existing, no changes needed)
  TxType.ClaimRewards → TxType.Transfer
  recipients = [{ address: walletBaseAddress, amount: '1' }]

HederaFactory → getTransferBuilder() → CoinTransferBuilder
  buildTransferData(): creates proto accountAmounts:
    [{ accountId: X, amount: -1 }, { accountId: X, amount: +1 }]
    (same accountId for both entries — intentional self-transfer)

Transaction sent to Hedera → reward flush triggers automatically

Transaction comes back for parsing/signing:
  TransactionBuilderFactory.from() → TransactionType.Send → getTransferBuilder()
  transaction.ts getTransferData()
    Before this fix: filters out the positive entry (accountID === sender)
                     → recipients[] empty → crash at recipients[0].address
    After this fix:  detects empty recipients + existing transfers → self-transfer fallback
                     → returns recipients[{ address: accountId, amount: '1' }]
  toJson() → recipients[0].address works correctly

Why no TransactionType.StakingClaim is needed

Other coins (ADA, TRX, SUI) use TransactionType.StakingClaim with a dedicated getStakingClaimRewardsBuilder(). HBAR doesn't because the claim is structurally identical to a regular transfer — the existing CoinTransferBuilder handles it. The only thing that was missing was the getTransferData() fix for the self-transfer case.

Changes in this PR

File	Change
transaction.ts	Self-transfer fallback in getTransferData() — when all positive-amount entries belong to the sender (sender == recipient), include the positive entry as the recipient instead of returning empty
coinTransferBuilder.ts	4 unit tests covering: build self-transfer, proto produces two separate accountAmounts entries, serialization round-trip, signing

No statics changes required. No new builder factory cases required.

[raksha-r7]

@claude please review

[raksha-r7]

nit: Consider adding a test or validation for the amount: '0' self-transfer edge case, since getTransferData() would return empty recipients in that scenario (the isPositive() check excludes zero).
otherwise lgtm