commitment: consolidate BAL-driven cache warming into single entry point

## Summary

Currently cache warming for block execution is split across multiple locations:

1. **`BlocksReadAhead`** (exec/blocks_read_ahead.go) — warms state domain (accounts, code, storage) for EVM execution
2. **BAL prefetch loop** in `executeBlocks` (exec3.go) — warms commitment domain (branch trie nodes) from BAL write set
3. **`TouchPlainKey` callback** → `BranchPrefetcher` — warms commitment domain during execution as keys are touched

When BALs become the primary source of truth for what a block will touch, all of this should be unified into a single `WarmBlockFromBAL(bal)` call that:

- Prefetches **state domain** data (accounts, storage, code) — replacing `BlocksReadAhead`
- Prefetches **commitment domain** data (branch trie nodes) — replacing the inline BAL loop and TouchKey callback
- Runs in a background goroutine as soon as the BAL is decoded, before execution starts

## Benefits

- Single place to understand all cache warming logic
- BAL gives complete write set ahead of time — no need for heuristic read-ahead
- Cleaner code path: one BAL → one warmup call → all domains
- Foundation for further BAL-driven optimizations (e.g., pre-computing state diffs)

## Context

- PR #19954 introduces the persistent BranchCache and BranchPrefetcher
- The BAL prefetch loop was added in the same PR
- `BlocksReadAhead` predates BALs and uses sender/recipient heuristics

## Blocked on

- BAL availability on mainnet (currently only on devnets)
- PR #19954 merge

🤖 Generated with [Claude Code](https://claude.com/claude-code)