rpc: keep trace_callMany bundles on the parent state boundary

## Problem

`trace_callMany` can read state from real transactions in the block after its selected historical parent.

For a historical parent block, the state reader starts at the boundary before the next block's user transactions. `doCallBlock` then calls `SetTxNum(baseTxNum + txIndex)` for every simulated call. The second simulated call therefore falls through to history as of the first real transaction in the next block. Keys changed by that real transaction, but not yet changed by the simulated bundle, leak into the result.

The same `doCallBlock` helper is also used for replaying real block transactions, where advancing the history reader is correct. The two modes need different state-boundary policies. The single-transaction `doCall` path replays a real transaction and should keep its existing indexed behavior.

## Proposed direction

- Make the history-reader policy explicit at the `doCallBlock` call boundary.
- Keep the reader fixed at the selected parent boundary for ad-hoc `trace_callMany` bundles. Earlier simulated calls should be represented only by the request's in-memory state and cache.
- Continue advancing the reader for actual block replay.
- Ensure state-diff clone readers use the same boundary as the call they describe.

## Acceptance criteria

- [ ] A regression test creates a real next-block transaction that changes a key untouched by the first simulated call.
- [ ] The second `trace_callMany` call observes parent state plus earlier simulated changes, not the real next-block change.
- [ ] Sequential block replay still observes the correct pre-state for each real transaction.
- [ ] State-diff, trace, and vmTrace modes follow the same boundary policy.
- [ ] The regression test fails before the fix.

## Related

- #22533
- #12607
- #23425