Make metrics 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 _InclusiveMetricsEvaluator objects are created and used on a per-file basis during scan planning. Much of this work doesn't vary by file though, the same filter is rewritten and bound every time. _StrictMetricsEvaluator is sometime reused sequentially. Neither can be concurrently reused safely because using them (by evaluating a file) changes their state.

This PR makes them stateless and moves the mutability into Visitor instances that are used on a per file basis and then discarded. This is both safer and more efficient. The benchmark-timings (see below) are sub-second but translate to real wall clock gains in the production workloads I ran with this change.

CODEX-generated summary follows:

Metrics filtering currently combines expensive, input-independent expression binding with mutable per-file metrics state. main constructs a new _InclusiveMetricsEvaluator for every file because concurrent calls on one instance could mix bounds and counts from different files. That avoids shared mutable state, but repeats the same preparation for every file.

This separates preparation from evaluation. The inclusive and strict evaluators retain only the bound expression and options, while each call creates a private visitor containing that file's metrics. A single prepared inclusive evaluator can therefore be shared across every manifest task in one planning call. Strict evaluation uses the same pattern so snapshot updates and other consumers do not retain the same latent concurrency hazard.

Summary

• Split inclusive and strict metrics evaluation into prepared facades and call-local visitors.
• Share one prepared inclusive evaluator across all manifest tasks in a plan.
• Remove the unused schema.as_struct() construction from inclusive evaluation.
• Add deterministic concurrent-use, prepared-state, record-count, planner-sharing, and downstream-consumer coverage.
• Add a realistic 15-leaf benchmark covering dense, fragmented, and fully pruned manifests.

Performance

I compared main and this branch using 1,000 files, a 102-column schema, and a 15-leaf predicate modeling five (event_day range AND region_id) branches. The serial manifest executor isolates planning work from thread scheduling. Values are median times from seven samples.

Manifest layout	main	This PR	Speedup
1 manifest × 1,000 files	346.460 ms	22.048 ms	15.71×
1,000 manifests × 1 file	347.152 ms	22.076 ms	15.72×

Eager preparation adds approximately 0.278 ms when one manifest has every file rejected before metrics evaluation (0.024 ms on main versus 0.302 ms here). Across 1,000 fully pruned manifests, the total difference is approximately 0.026 ms (0.636 ms versus 0.662 ms).

Testing

• pytest tests/expressions/test_evaluator.py tests/table/test_metrics_evaluator_planning.py tests/table/test_init.py tests/table/test_delete_file_index.py tests/table/test_snapshots.py tests/table/test_validate.py (241 passed)
• pytest tests/benchmark/test_metrics_evaluator_benchmark.py -m benchmark (4 passed)
• UV_NO_CONFIG=1 .venv/bin/prek run -a