Fix Tron solverLock MsgValueMismatch revert with native reward token

[Martin9204]

Summary

• TronTransactionProcessorWorker recomputed call_value only from the lock amount when the lock token was native TRX, ignoring the reward. When the reward token was native, msg.value had to include the reward too — otherwise the Train contract reverted with MsgValueMismatch() (selector bc6f88c5).
• The shared EVM TransactionBuilderService.BuildSolverLockTransactionAsync already computes the correct native amount ((isNative ? amount : 0) + (isNativeReward ? reward : 0)) and returns it in PrepareTransactionDto.Amount. The Tron worker now uses that value instead of recomputing it.
• All Redeem/Refund builders set Amount = "0", so this change is universal across lock/redeem/refund payloads.

Background

Observed three on-chain solverLock reverts on Tron Nile (e.g. tx 7dc8bcc9e5413a155bac9705131e02ad91b4e3b385f2ba7b2f551e3219571b3b) with contractResult=bc6f88c5 = MsgValueMismatch(). The selector being sent (62bfdaab) matches the deployed contract's bytecode dispatcher; the revert happened inside the function on the msg.value check, not at dispatch. (Tronscan's UI shows wrong selectors 720444a4/6df0184a because Tron's on-chain ABI drops tuple components, but that's purely cosmetic — unrelated to this fix.)

Test plan

• Submit a solverLock with RewardToken = native TRX and TokenContract = TRC-20 — should now succeed (previously reverted)
• Submit a solverLock with both TokenContract and RewardToken native — msg.value should equal amount + reward
• Submit a solverLock with both non-native — msg.value should be 0 (unchanged behavior)
• Verify Redeem/Refund txs still send call_value=0 (since their builders return Amount="0")

🤖 Generated with Claude Code