kona-sp1-proposer: investigate and share preimage cache across witness runs

## Summary

Witness generation currently creates a fresh in-memory `InteropHost` preimage cache for every range and consolidation pass. With multiple span chunks, fetched L1/L2 preimages may therefore be fetched repeatedly.

I noticed that witness gen takes quite some time for a 60s span. And I suspect that it's partly due to the fact that every prove chunk refetches common preimages from RPCs. But let's quantify this more precisely: First measure the potential reuse, then introduce a shared cache if the results show meaningful benefit.

## Tasks

- Generate witnesses for representative consecutive spans and compare their preimage keys.
- Record how many preimages and how many bytes are common between the spans.
- If the overlap is meaningful, reuse a shared content-addressed preimage cache across witness-generation invocations.
- Keep per-span local boot inputs isolated.
- Add a focused test proving that common preimages are reused without changing generated witnesses or outputs.

Start by running witness generation for representative consecutive spans and comparing the preimage keys and byte counts across range and consolidation passes. Read the InteropHost preimage cache handling and keep per-span boot inputs isolated while evaluating reuse. Done means a focused test shows common preimages are reused without changing generated witnesses or outputs.

Written by the indexing model from the issue text.