optimize(LargeSmtForest): reduce repeated history scans in historical open

[AlexWaker]

Close #923.

This change reduces repeated scans of the historical change set during a single historical LargeSmtForest::open() query.

The implementation does a single pass over view.changed_keys(), collects the entries relevant to the queried leaf and the deepest sibling leaf, and then reuses those prefiltered changes in both leaf reconstruction and path reconstruction. The intent is to reduce repeated work on the historical open path without changing the current correctness semantics.

I reran the relevant large_smt_forest query benchmarks locally and compared this change against a clean baseline worktree on the same machine. To avoid over-interpreting Criterion's saved baseline state, I did not rely on the change line in the Criterion output. Instead, I compared the medians directly from the time triplets across repeated runs.

For the focused large_smt_forest_persistent_open_historical_tree benchmark, I ran 3 full rounds on each side. The results were effectively tied:

• This change: 76.431 µs, 77.594 µs, 76.242 µs
• Baseline(HEAD): 76.789 µs, 77.482 µs, 77.213 µs

Average median:

• This change: 76.756 µs
• Baseline(HEAD): 77.161 µs

That is approximately 0.525% faster on average for this change. Given that the changes in #886 was about 1.5% slower, and this change recovers about 0.5%, the net performance overhead is reduced to under 1%.

Do you think this improvement is acceptable, or should we try a more aggressive approach? @iamrecursion

[iamrecursion]

This looks generally good to me. I can't see any obvious way that we could speed it up even more, so I'm inclined to say that this is good. Correctness obviously takes precedence over speed, and this is very close to the performance of the slightly buggy version.

Please do add a changelog entry for this!

[huitseeker]

Lovely, thanks @AlexWaker !