feat: fix contract creation tx receipt compatibility with Ethereum spec

[mwb-al]

Description:
There is a discrepancy between Hedera and standard Ethereum behavior regarding the to field in transaction receipts for contract creation transactions:

• Standard Ethereum JSON-RPC: When a contract is created via a transaction with a null to field, the transaction receipt also reports a null to field
• Hedera Mirror Node: Automatically populates the to field with the address of the newly created contract

This inconsistency affects both eth_getTransactionReceipt and eth_getBlockReceipts endpoints, causing compatibility issues with Ethereum tooling that expects standard transaction receipt formats.

Solution

This PR implements a centralized fix in TransactionReceiptFactory.createRegularReceipt() to correct the to field behavior for contract creation transactions. The solution:

1. Checks for direct contract creation: Examines if a contract was directly created by the transaction by verifying if the contract's ID appears in the created_contract_ids array
2. Sets to field to null: When direct contract creation is detected, the to field is set to null to match standard Ethereum JSON-RPC behavior
3. Ensures consistent behavior: Since both affected endpoints (eth_getTransactionReceipt and eth_getBlockReceipts) use the same factory method, this change ensures consistent behavior across both endpoints

This change affects:

• eth_getTransactionReceipt - Individual transaction receipt queries
• eth_getBlockReceipts - Batch transaction receipt queries for entire blocks

Related issue(s):

Fixes #3814

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[lfdt-bot]

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...b/services/ethService/blockService/BlockService.ts	0.00%	4 Missing ⚠️
...thService/transactionService/TransactionService.ts	0.00%	1 Missing and 1 partial ⚠️
...vices/ethService/ethCommonService/CommonService.ts	0.00%	0 Missing and 1 partial ⚠️

@@           Coverage Diff           @@
##             main    #3825   +/-   ##
=======================================
  Coverage        ?   46.67%           
=======================================
  Files           ?       80           
  Lines           ?     4692           
  Branches        ?      975           
=======================================
  Hits            ?     2190           
  Misses          ?     2153           
  Partials        ?      349           

Files with missing lines	Coverage Δ
...lay/src/lib/factories/transactionReceiptFactory.ts	68.42% <ø> (ø)
...vices/ethService/ethCommonService/CommonService.ts	24.77% <0.00%> (ø)
...thService/transactionService/TransactionService.ts	39.36% <0.00%> (ø)
...b/services/ethService/blockService/BlockService.ts	28.77% <0.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[acuarica]

Does this change only impact eth_getBlockReceipts, or eth_getTransactionReceipt as well? Because there is test change for eth_getTransactionReceipt, but I would have assumed that TransactionService.ts::handleRegularTransactionReceipt needs to be changed as well.

In any case, we should update both this PR and issue descriptions to match the actual scope of this PR.

[quiet-node]

LGTM

[mwb-al]

@quiet-node I have updated the branch with the latest main and made sure all tests pass.

[quiet-node]

@quiet-node I have updated the branch with the latest main and made sure all tests pass.

@mwb-al hey thanks looks like the DCO is still failing. Please update the branch and will approve again