chain/ethereum: send eth_getBlockReceipts block hash as plain string param (#5835)

[cargopete]

Summary

Fixes #5835. graph-node sends eth_getBlockReceipts with the block hash as an
EIP-1898 object param ([{"blockHash":"0x.."}]) rather than the plain string
form (["0x.."]). Some clients (e.g. taraxa-node) only accept the plain string
and reject the object with INVALID_PARAMS.

This happens because both block-receipts call sites go through alloy's typed
Provider::get_block_receipts(BlockId), and BlockId::from(block_hash)
serializes a BlockId::Hash as {"blockHash": ".."}.

When the capability probe (check_block_receipt_support) fails on such a node,
graph-node caches "block receipts unsupported" and permanently falls back to one
eth_getTransactionReceipt per transaction — correct data, but materially slower
ingestion and far more RPC load.

Fix

Add a small helper that issues a raw request with the hash as a plain string:

alloy.client().request("eth_getBlockReceipts", (block_hash,)) // B256 -> "0x.." -> ["0x.."]

Both call sites (check_block_receipt_support and fetch_block_receipts_with_retry)
now route through it. The plain-string form is accepted by all known
implementations, and remains valid for nodes that currently work (they accept
both forms).

Testing

• New unit test block_receipts_param_is_plain_hash_string asserting the new
  param serializes to a string array ["0x.."], and pinning the old object form
  as a regression guard.
• Existing ethereum_adapter unit tests pass (incl. test_check_block_receipts_support).
• cargo fmt, cargo clippy --all-targets, and cargo check --release clean for
  graph-chain-ethereum.

Trade-off

A node that accepts only the EIP-1898 object form and not the plain string
would regress. In practice this is the rarer (and arguably non-conformant) case —
the plain hash string is the canonical Geth form and, per the issue reporter, the
form "all implementations" accept. Flagging it explicitly for maintainer review.

[lutter]

Have you reported this upstream to alloy? I'd be curious what their take is

[incrypto32]

Fix looks right.

nit: On the test it doesn’t actually call the helper, so it’d still pass even if the fix got reverted. It’s not really testing our code. I’d just drop it, test_check_block_receipts_support already covers this.

I’d prefer this fixed upstream in alloy rather than worked around here. Feels like an alloy-side fix. Did you get a chance to report it upstream? if they push back let’s just land this and rip it out once alloy ships the fix.

[cargopete]

Thanks both.

@incrypto32 - dropped the serialization test; you're right that it pinned serde_json's behaviour rather than our code path. test_check_block_receipts_support exercises the real path now (it routes through the new helper).

@lutter @incrypto32 - reported upstream: alloy-rs/alloy#4049, asking whether get_block_receipts should serialize a bare BlockId::Hash as a plain string for broader node compatibility, or whether they consider such nodes non-conformant.

Happy to treat this PR as a stopgap and rip it out once alloy ships a fix. If they decide it's the node's problem, this keeps the affected indexers on single-call block receipts in the meantime rather than degrading to per-transaction fetching.

[cargopete]

Upstream fix is now open as a PR too: alloy-rs/alloy#4050 (introduces a BlockReceiptsParams wrapper that serializes a block-hash param as a plain string for eth_getBlockReceipts). If/when that lands and we bump alloy, this workaround can be reverted.

[incrypto32]

Thanks @cargopete for digging into this and reporting it upstream. Seems alloy fix is now merged (alloy-rs/alloy#4052) and covers our exact call path, so we won’t need to carry this workaround. Going to close it out, we’ll pick the fix up for free on the next alloy bump. Tracking in #5835 until then.