Make partition expression evaluation stateless

[dossett]

I used CODEX to analyze this problem and create this PR. I've reviewed the code and tests and stand by them. This summary is written completely by a human (me) other than very light copy editing by an LLM.

Currently, because _ExpressionEvaluator can't be safely shared one is created per file. That's expensive relative to actually evaluating the expression. This change makes _ExpressionEvaluator shareable by moving the mutable parts into a new _ExpressionEvaluationVisitor which stays local to the per-file work of evaluation.

These benchmarks are showing improvements in sub-second times, but in the production workloads I tested this on it did translate to real wall clock improvement. But irrespective of performance gains the new _ExpressionEvaluator is safer since nothing was preventing its accidental concurrent reuse in the future.

CODEX-generated summary follows:

Partition pruning currently binds the same projected expression for every data file because _ExpressionEvaluator stores the current record as mutable instance state. That repeated preparation is expensive, but sharing the existing evaluator across workers would allow concurrent calls to mix records.

This separates preparation from per-record evaluation. _ExpressionEvaluator binds the expression once, while every call creates a private _ExpressionEvaluationVisitor containing that call's record. Manifest planning can therefore prepare one evaluator per partition spec and safely share it across manifests and workers. This provides the construction-reuse benefit targeted by #3656 without depending on files within a manifest remaining sequential, and it also benefits one-file manifests.

Summary

• Split the prepared expression evaluator from the call-local mutable visitor.
• Reuse one prepared partition evaluator per partition spec during manifest planning.
• Add deterministic concurrent-use, prepared-state, and planner-sharing coverage.
• Add a benchmark using a realistic 15-leaf predicate across dense and one-file manifests.

Performance

I compared this branch with main using the partition-evaluator workload in this PR. It evaluates 1,000 files with two identity partition fields and a 15-leaf predicate modeling five (event_day range AND region_id) branches. Timings are medians from seven samples of five iterations.

Manifest layout	main	This PR	Speedup
1 manifest × 1,000 files	187.928 ms	14.413 ms	13.04×
1,000 manifests × 1 file	188.000 ms	14.584 ms	12.89×

The improvement comes from binding the projected partition expression once per partition spec instead of once per file. This is an isolated partition-pruning benchmark rather than an end-to-end scan-planning measurement.

Testing

• pytest tests/expressions/test_visitors.py tests/table/test_partition_evaluator_planning.py tests/table/test_init.py (200 passed)
• pytest tests/benchmark/test_partition_evaluator_benchmark.py -m benchmark (2 passed)