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 用例。检查上游对 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).