fix(proxyd): forward out-of-range block requests to backend

[sebastianst]

Summary

Fixes #546.

• Removes the ErrRewriteBlockOutOfRange / ErrBlockOutOfRange errors entirely
• Requests for blocks beyond latest are now forwarded to the backend instead of being intercepted by the rewriter
• The backend returns the spec-compliant response (e.g. {"result": null} for eth_getBlockByNumber with a future block)

Previously, proxyd returned HTTP 400 with JSON-RPC error code -32019 ("block is out of range") for methods like eth_getBlockByNumber when the requested block was beyond latest. Per the Ethereum JSON-RPC spec, these methods should return null, not an error. This also broke ethclient which expects ethereum.NotFound for missing blocks, not an RPC error.

The rewriter's job is to translate block tags (latest, safe, finalized) to concrete numbers and enforce max block ranges — not to decide whether a specific block number exists. That's the backend's responsibility.

Test plan

• Unit tests updated — out-of-range cases now expect RewriteNone (pass-through) instead of RewriteOverrideError
• Integration tests updated — verify requests for future blocks are forwarded to backend and return null
• Full test suite passes (go test ./... -timeout 10m)

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 57.52%. Comparing base (f9bf450) to head (54d68c5).

Files with missing lines	Patch %	Lines
proxyd/backend.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #547      +/-   ##
==========================================
- Coverage   57.61%   57.52%   -0.10%     
==========================================
  Files          94       94              
  Lines       14204    14194      -10     
==========================================
- Hits         8184     8165      -19     
- Misses       5522     5531       +9     
  Partials      498      498              

Flag	Coverage Δ
proxyd	71.08% <0.00%> (-0.24%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
proxyd/rewriter.go	73.95% <ø> (-2.28%)	⬇️
proxyd/backend.go	79.30% <0.00%> (-0.54%)	⬇️

🚀 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.

[serpixel]

Looks good to me, but @jelias2 may be better suited here.

[jelias2]

So I'm going to propose some changes to this. I think you found a bug, we definetly want proxyd to be eth rpc compliant where possible so this is a bug, however we don't want to send requests to our backends if the the backend consensus group does not recognize the block range as valid.

So I think the approraite thing to do would be keep the checks and do not forward to the backends, yet change the error response to be eth compliant and debug log the action

[sebastianst]

works for me!