bug: EthTxIndex -1 sentinel wraps to MaxUint64 in ReceiptsFromCometBlock, breaking JS clients

[Aboudjem]

Bug Description

In rpc/backend/comet_to_eth.go, ReceiptsFromCometBlock casts TxResult.EthTxIndex directly to uint without resolving the -1 sentinel value:

TransactionIndex: uint(txResult.EthTxIndex), // #nosec G115

When EthTxIndex == -1 (meaning "not yet determined by indexer"), int32(-1) wraps to uint64(18446744073709551615).

Reproduction

1. Run a cosmos/evm chain and submit EVM transactions during fast block production
2. If the indexer hasn't assigned EthTxIndex yet, it is stored as -1
3. Call eth_getTransactionReceipt for that transaction
4. The transactionIndex field in the receipt is 0xffffffffffffffff instead of the correct index

Impact

• All viem/wagmi clients throw IntegerOutOfRangeError when receiving this receipt
• waitForTransaction hangs indefinitely because the receipt is unparseable
• Affects any chain running cosmos/evm with active transaction throughput
• PR fix: wrong TransactionIndex in receipt #723/fix: wrong TransactionIndex in receipt #806 fixed TransactionIndex to use EthTxIndex instead of loop index, but did not handle the -1 sentinel case

Expected Behavior

The -1 sentinel should be resolved to the correct transaction index (the loop counter), matching the existing fallback pattern in tx_info.go:68-76:

if txResult.EthTxIndex == -1 {
    txResult.EthTxIndex = int32(i)
}

Proposed Fix

Add sentinel resolution before the uint cast in ReceiptsFromCometBlock, matching the pattern already used in GetTransactionByHash.

[linear]

EVM-437