Explorer integration: Blockscout and Atlas support for 0x76 transactions

## Summary

Integrate block explorer support for ev-reth chains, targeting both Blockscout (open-source, self-hosted) and Atlas (in-house explorer). Both need custom rendering for Evolve-specific transaction types (0x76 batch calls, fee sponsorship).

## Motivation

Every production chain needs a block explorer. ev-reth's custom transaction type (0x76) with batch calls and fee sponsorship won't render correctly in stock explorers -- it will show as an unknown transaction type with opaque calldata. Both Blockscout (for self-hosted/community deployments) and Atlas (for first-party deployments) need to understand Evolve primitives.

## Scope

### 1. RPC layer (shared by both explorers)

The RPC responses from ev-reth must expose 0x76 fields in a way explorers can consume:

- `eth_getTransactionByHash` must include `feePayer` (address), `calls` (array of {to, value, input}), and `txType: "0x76"`
- `eth_getTransactionReceipt` must indicate effective gas payer and per-call log attribution
- This is the foundation -- get the RPC right and both explorers benefit

### 2. Blockscout integration
- Document archive node configuration for ev-reth
- Docker compose setup for Blockscout + ev-reth
- Verify standard Ethereum transactions (types 0, 1, 2, 3) render correctly
- Verify RPC compatibility (Blockscout's required endpoints vs ev-reth's exposed endpoints)
- Custom 0x76 rendering via Blockscout's plugin/extension system:
- **Batch calls**: Display individual calls within a 0x76 transaction instead of opaque calldata
- **Fee sponsorship**: Show `feePayer` address, distinguish executor vs sponsor
- **Transaction type label**: "EvNode Transaction" instead of "Unknown Type"

### 3. Atlas integration
- Ensure Atlas consumes the extended RPC fields for 0x76 transactions
- Native rendering of batch calls, sponsorship, and Evolve-specific metadata
- Atlas can go deeper than Blockscout since it's in-house: lane attribution, per-call gas breakdown, sponsor history, etc.

### 4. ev-node considerations
- Explorers need to handle ev-reth's block structure (no ommers, modified consensus fields)
- Block finality semantics: ev-node-derived finality vs explorer default assumptions
- If the chain uses ev-node for DA, explorers should ideally link to DA layer block references

## Prior art

- [Blockscout OP Stack Setup](https://docs.optimism.io/chain-operators/tools/explorer)
- [Blockscout GitHub](https://github.com/blockscout/blockscout) -- `production-optimism` branch for OP Stack
- [Blockscout Custom Extensions](https://docs.blockscout.com/)