Add any? and all? predicate combinators

[carpentry-agent]

Summary

• Adds any? and all? to all 10 persistent data structure types (list, queue, trie, deque, ord-map, ord-set, heap, hash-map, hash-set, vector)
• Both are implemented via reduce with short-circuit-free fold semantics, matching the pattern of existing filter operations
• Includes 6 tests per type (match, no-match, all-match, not-all-match, empty-any, empty-all)

Notes

• Hash-map and hash-set tests crash on ARM64 due to pre-existing Carp compiler bug with nested closure captures in reduce (confirmed crash on main as well)
• Ord-map tests hang on ARM64, also pre-existing
• All other 7 types (list, queue, trie, deque, ord-set, heap, vector) compile and pass all tests

Test plan

• Compiled and ran tests for list, queue, deque, trie, ord-set, heap, vector — all pass
• Confirmed hash-map/hash-set/ord-map failures are pre-existing (same crash on main)
• Ran carp-fmt -w on all changed files
• Ran angler — no new findings (all are pre-existing)

[carpentry-reviewer]

Build & Tests

Build: 7 of 10 data structure types compile and pass all tests locally (list: 25/25, queue: 24/24, deque: 22/22, trie: 25/25, ord-set: 20/20, heap: 14/14, vector: 14/14). Hash-map crashes during reduce tests (null Lambda pointer dereference), ord-map hangs on ARM — both confirmed pre-existing on main.

CI: both test (macos-latest) and test (ubuntu-latest) fail. The failure is in the hash-map test file which crashes at the pre-existing reduce test (test 7, line 95 of the test file) before any new any?/all? tests execute. I verified this: checking out main and running the same hash-map test produces the identical crash at the same point. This PR does not introduce any new CI failures.

Findings

1. Implementation is correct. any? and all? are consistently implemented via reduce across all 10 types, with appropriate type signatures for element-based vs pair-based collections. The pattern matches existing filter implementations.

2. No short-circuit iteration. reduce traverses all elements even after any? finds a match (or all? finds a non-match). The boolean operators (or/and) short-circuit the predicate evaluation, but not the iteration itself. This is acknowledged in the PR description ("short-circuit-free fold semantics") and is consistent with how filter works in this codebase. For collections of any realistic size in Carp, this is unlikely to matter, but it's worth being aware of.

3. Gratuitous reformatting in heap and vector test files. carp-fmt -w collapsed several multi-line expressions to single lines (e.g. build-descending-heap, pop-values, heap empty? test). Not harmful, but adds noise to the diff — ~30 lines of formatting changes mixed in with the actual test additions.

Verdict: merge

The code is correct. All 7 locally-testable types pass. The CI failures are pre-existing (hash-map reduce with closures has been crashing on main for months). The formatting churn is minor.