Comprehension macros are O(n²) in cel-rust 0.14.5; upstream fix for `map` is on master

cel-rust 0.14.6 または 0.15 を待ってから更新し、#45 プロトタイプの bench.py にある cs/c ケースを再実行します。upstream の map の修正で filter、all、exists、exists_one もカバーされるか確認し、tests/test_performance_verification.py に 10,000 要素のパフォーマンスチェックを追加します。大規模なリスト内包表記が依然として遅い場合は、標準ライブラリのリファレンスを更新します。

Found while benchmarking for #45. Executing items.filter(i, i % 3 == 0).map(i, i * i).size() against a Context holding an int list scales quadratically with the list length (release build, min of repeats):

Each doubling costs ~4×. cel-rust 0.14.5's comprehension macros rebuild the accumulator list on every append (Value::List is an Arc<Vec<_>>, so appending clones the vector), which makes map/filter over anything beyond a few thousand elements unusable. Nothing in this wrapper contributes; a dict context and a Context behave identically.

Upstream already has the fix for map on master, unreleased: cel-rust/cel-rust#341 "perf(macros): map mutates List in place" (merged 2026-09-13, on top of "perf(map): Added mutable List used in map"). It is not clear from the PR title whether filter, all, exists and exists_one got the same treatment.

To do

• When the next cel-rust release (0.14.6 or 0.15) ships, bump and re-run the table above; add a test in tests/test_performance_verification.py that pins a comprehension over a 10,000-element list under a generous bound (say 200 ms) so a regression is caught.
• If filter is still quadratic after the bump, raise it upstream with the numbers.
• Until then the standard-library reference should say that comprehensions over large lists are slow in the current cel-rust, since policy engines routinely filter lists of thousands of records.

Benchmark script: the cs/c cases in the #45 prototype's bench.py (measured on 4 cores).