blockifier: pre-reserve capacity when rebuilding trimmed state maps

[gkaempfer]

Summary

Follow-up performance optimization to #14625.

StateMaps::trim_to_accessed_keys rebuilds each HashMap via .collect() on a filter_map iterator over the accessed-keys BTreeSet. filter_map's size hint has a lower bound of 0 (since the filter can drop any number of elements), so collect()'s internal reserve() call is a no-op — the resulting HashMap grows through repeated reallocation and rehashing as elements are inserted instead of being sized once up front.

This PR pre-reserves capacity for min(keys.len(), map.len()) before extending, which is a tight upper bound on the final size: accessed keys are (almost always) a subset of the map being intersected, since get_os_initial_reads already force-reads the nonce/class-hash/compiled-class-hash of every contract that ends up in accessed_keys.

Why this matters: trim_to_accessed_keys runs once per block in apollo_batcher's hot path. Avoiding the incremental grow-and-rehash cycle removes a constant-factor overhead from a function whose cost already scales with block size.

Test plan

• cargo build -p blockifier
• cargo clippy -p blockifier --lib (clean)
• SEED=0 cargo test -p blockifier --lib state::cached_state (43 passed)
• scripts/rust_fmt.sh (no diff beyond the change)
• Reviewed by an Opus subagent for correctness and style; two nits addressed (tighter capacity bound, comment length)

---

Generated by Claude Code

[cursor]

PR Summary

Low Risk
Pure allocation/performance tweak with identical intersection semantics; no auth, state correctness, or API changes.

Overview
Performance follow-up to earlier blockifier caching work: StateMaps::trim_to_accessed_keys still rebuilds each map by intersecting with accessed keys, but the inner intersect helper no longer uses collect() on a filter_map alone.

Because filter_map reports a size hint lower bound of 0, HashMap::collect() did not pre-size the result and the map grew via repeated reallocations. The change builds the map with HashMap::with_capacity(keys.len().min(map.len())) and extends the filtered pairs, matching the tight upper bound on how many entries can survive the intersection.

Behavior is unchanged; this targets per-block overhead on the batcher path where trim_to_accessed_keys runs often.

^{Reviewed by Cursor Bugbot for commit 305e3ab. Bugbot is set up for automated code reviews on this repo. Configure here.}

[reviewable-StarkWare]

This change is 

[github-actions]

Artifacts upload workflows:

• Started at 2026-08-10T07:10:01Z