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.