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.