perf(eval): batch rule loading to avoid O(N²) index rebuilds

[mostafa]

Summary

Engine::add_rule rebuilds the inverted index and per-field bloom on every call, so loading a rule set with add_rule in a loop is O(N²) in the rule count. The CLI validate command exercises this exact path, and on the 3120-rule SigmaHQ corpus it appeared to hang because it was paying ~3K full index rebuilds. CorrelationEngine::add_collection hit the same trap via the inner engine, so rsigma eval, the daemon, and every RuntimeEngine caller shared the bug.

This PR adds batched-load primitives to rsigma-eval and routes the slow callers through them.

Impact

rsigma validate on the full 3120-rule SigmaHQ corpus on a MacBook M4 Pro:

Build	Before	After
Debug	killed at 60s+ (never completed)	2.2s
Release	~25-30s extrapolated from 2390-rule subset	0.5s

The win (O(N)+O(1) → O(N)) comes from collapsing N per-rule rebuilds into a single rebuild: roughly an N× reduction in RuleIndex::build and FieldBloomIndex::build calls (3120 → 1), and the bloom builder is the dominant cost because it sweeps every detection on every rebuild to collect needles, trigram-dedup, and size each per-field filter. The same fix applies to the correlation engine, so daemon and eval rule loads also drop from O(N²) to O(N).

Changes

• Engine::add_rules<'a, I: IntoIterator<Item = &'a SigmaRule>>(&mut self, rules: I) -> Vec<(usize, EvalError)> compiles each rule (applying configured pipelines), collects per-rule compile errors without aborting the batch, and rebuilds the engine indexes exactly once.
• Engine::extend_compiled_rules<I: IntoIterator<Item = CompiledRule>> does the same for pre-compiled rules, used by the correlation engine to avoid double pipeline application.
• Engine::add_rule and Engine::add_collection share a new compile_with_pipelines helper so single- and batch-add paths stay behaviourally identical.
• rsigma validate now sends the whole parsed collection through add_rules while preserving the existing per-rule compile-error reporting.
• CorrelationEngine::add_collection compiles each rule sequentially (with its own pipelines, custom-attribute handling, and rule_ids tracking), then pushes the resulting batch through extend_compiled_rules once. The single-rule CorrelationEngine::add_rule is unchanged.
• crates/rsigma-eval/README.md API table now lists the two new methods.

Tests

• test_add_rules_matches_per_rule_loop: batched and per-rule paths produce identical evaluation verdicts across a mix of indexable and substring rules.
• test_add_rules_collects_errors_without_aborting: a bad rule between two good ones is reported via the returned (index, error) list while both good rules end up loaded.
• test_add_rules_scales_linearly_on_large_corpus: loads 2000 generated rules and asserts the call completes inside a deliberately generous 30s ceiling; the previous per-rule path would have timed out.

Test plan

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo test --workspace --all-features
• rsigma validate ../sigma/rules/ against the full SigmaHQ corpus (3120 rules) in both debug and release builds.