Avoid duplicate in-flight RPC slot fetches

[rappie]

Summary

This PR is vibecoded and loosely reviewed manually.

Tested locally:

• Testsuite passes
• Added tests pass
• Echidna built with HEVM including this code works as expected

Result:

• 10-fold decrease in RPC fetches for fuzzing uniswap v3 pools with 12 echidna workers (~15,000 -> ~1,500)

Below the line is AI generated

---

Description

This PR reduces redundant RPC load when multiple workers request the same storage slot concurrently.

It does this in two steps:

• routes oracle storage reads through the existing slot cache fetch path
• adds single-flight tracking for in-flight slot fetches, keyed by resolved block, address, and slot

Motivation

During Echidna fork fuzzing, workers can race on the same uncached storage slot. Before this change, each worker could issue its own identical eth_getStorageAt request before the first result populated the cache.

On live fuzzing runs this caused avoidable duplicate RPC traffic and could quickly hit provider call limits.

Behavior

If a slot fetch is already in progress, concurrent callers now wait for that same fetch instead of starting another identical RPC request. Once the fetch completes, all waiters receive the same result and the normal cache remains the source of truth for later reads.

The in-flight key includes the resolved block so reads at different fork blocks remain isolated.

Checklist

• tested locally
• added automated tests
• updated the docs
• updated the changelog

[msooseth]

Honestly, this changeset is large. I asked an AI to make a smaller one, #1072

That 1072 is quite a bit smaller:

  ┌──────────┬───────┬─────────┬────────────┬─────────────┐
  │          │ Added │ Removed │ Net growth │ Total churn │
  ├──────────┼───────┼─────────┼────────────┼─────────────┤
  │ This PR  │ +77   │ −40     │ +37        │ 117         │
  ├──────────┼───────┼─────────┼────────────┼─────────────┤
  │ PR #1070 │ +116  │ −38     │ +78        │ 154         │
  └──────────┴───────┴─────────┴────────────┴─────────────┘

[msooseth]

So I'm closing this, because it seems too much to me to change. Honestly, likely 1072 needs quite a bit of love, too. I am not saying it's MUCH better, because both will probably need hand-rewriting. But at least the other one is smaller change :)