chore(testing): Anvil-based EVM integration test harness

[Emmyt24]

Depends on: #218. Blocks: #221, #222, #224, #225, #226 (all need it to be testable).

Description

Stellar work is testable locally: the StellarNetwork::Standalone variant
(crates/wallet-core/src/signer.rs) exists specifically so
contributors can run against a local node "without depending on public testnet availability or
friendbot rate limits", and just test-live gates network tests behind OCTO_LIVE_TESTS=1.

EVM work needs the same. Without a local devnet, every downstream issue is either untested or
dependent on a flaky public testnet — and #222 (reorg handling) is untestable at all, because you
cannot induce a reorg on a public network on demand. Anvil (from Foundry) can, via
anvil_snapshot/anvil_revert.

Requirements and context

• Tests must skip cleanly, not fail, when Anvil is absent, mirroring how the Horizon live tests
  gate on OCTO_LIVE_TESTS. A contributor without Foundry must still get a green just test.
• Each test needs an isolated chain instance — a random free port and its own process, so tests can
  run in parallel without shared-state flakiness.
• Deterministic accounts: use Anvil's standard mnemonic so funded test accounts are reproducible.
• Deploy a mock ERC-20 with configurable decimals — 6 (USDC), 18 (DAI), and 0 must all be
  exercised, since decimal handling is where feat(store): Arbitrary-precision amounts — replace i64 stroops with NUMERIC(78,0) #215 and feat(store): ERC-20 token registry #223 will break.
• Expose reorg controls (anvil_snapshot, anvil_revert, evm_mine, anvil_setNextBlockBaseFeePerGas)
  as harness methods — this is the deliverable feat(ingest): Confirmation depth and reorg handling for EVM deposits #222 depends on most.
• Process cleanup must be reliable on panic, or a failing test run leaves orphan Anvil processes.

Suggested execution

Branch: chore/anvil-integration-harness

Implement changes

• Add crates/evm-rpc/tests/common/anvil.rs (or a small test-support crate if feat(ingest): EVM ingest worker — ERC-20 Transfer log scanning #221/feat(wallet): EVM deposit sweep engine #224 also need
  it): an AnvilInstance guard that spawns on a free port, waits for readiness by polling
  eth_chainId, and kills the process in Drop.
• Add a MockErc20 deploy helper with parameterised decimals, plus mint/transfer helpers so
  tests can produce real Transfer logs.
• Add reorg helpers: snapshot(), revert_to(id), mine(n), set_base_fee(x).
• Add just test-evm to the justfile alongside test-live, and gate on an
  OCTO_EVM_TESTS env var plus an Anvil-on-PATH probe.
• Document Foundry installation in CONTRIBUTING.md.

Test and commit

• A self-test proving the harness works: start Anvil, mine blocks, assert eth_blockNumber advances.
• A self-test proving snapshot/revert actually reorgs: mine a block containing a Transfer,
  snapshot, mine more, revert, and assert the transaction receipt is gone. If this test does not
  pass, feat(ingest): Confirmation depth and reorg handling for EVM deposits #222 cannot be verified.
• A test that the suite skips (not fails) when Anvil is unavailable.
• A test that Drop kills the process even when the test panics.
• Add CI: install Foundry and run just test-evm.

Example commit message

chore(testing): add Anvil-based EVM integration harness

Gives EVM work the local-devnet story Stellar already has via
StellarNetwork::Standalone, with per-test isolated instances on random
ports and deterministic funded accounts.

Exposes anvil_snapshot/anvil_revert so reorg handling (#222) is testable
at all — a reorg cannot be induced on a public testnet on demand.

Skips cleanly when Foundry is absent so `just test` stays green.

Refs #219

Guidelines

Good first issue — self-contained, no fund-loss risk, and it unblocks five other issues. Prioritise
reliability: a flaky harness poisons every downstream PR.

---

---

Phase 3 — Inbound / deposits

---

[Peculiarr7]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. I’ll prioritize this immediately and ensure a reliable solution is delivered as soon as possible. Thank you!

[bobo-24]

Hi! I’m a full-stack developer with a strong blockchain background, and I’m confident I can resolve this issue quickly and effectively. I’ll deliver a clean, reliable solution with immediate attention to detail, ensuring it’s completed as soon as possible. Please assign it to me—I’m ready to get started right away.