Issue Description

The eth_sendRawTransaction endpoint returns a 500 error instead of a proper 400 client error when receiving transactions with malformed RLP payloads. The error occurs during transaction parsing in Precheck.parseTxIfNeeded when ethers.js encounters unexpected data after what should be a complete RLP transaction.

Steps to Reproduce

1. Send a malformed transaction to the eth_sendRawTransaction endpoint
2. Example problematic transaction:

0xf8748201280585800e8dfc0085800e8dfc00832dc6c094aca85ef7e1fce27079bbf99b60fcf6fd19b99b248502540be40080c001a0210446cfb671c3174392410d52fa3cd58723d8417e40cc67c6225b8f7e3ff693a02674b392846c59f783ea96655d39560956dd987051972064a5d853cea0b6f6d711

Current Behavior

• Error: unexpected junk after rlp payload (argument="data", value=<transaction-hex>, code=INVALID_ARGUMENT, version=6.13.5)
• Returns HTTP 500 status code
• Error is not properly mapped to a client error

Expected Behavior

• Return HTTP 400 status code
• Map to a proper client error like INVALID_ARGUMENTS
• Include helpful error information for client debugging

Root Cause

The error occurs in Precheck.parseTxIfNeeded when calling Transaction.from(transaction) from ethers.js. The specific error (INVALID_ARGUMENT) isn't handled in the error mapping logic, so it's treated as an unknown internal error (500).

Proposed Solution

1. Add specific error handling in parseRawTxAndPrecheck or genericErrorHandler to detect ethers.js "unexpected junk after rlp payload" errors, or more generic to check for INVALID_ARGUMENTS code
2. Map these errors to the proper predefined.INVALID_ARGUMENTS JsonRpcError
3. Add tests to verify proper error handling for malformed transactions