filter / filters bucket aggregations rejected on _elastic/_search and native search

Summary

On 0.8.x, the filter (singular) and filters (plural) bucket aggregations appear to be rejected on both the native search API and the ES-compat _elastic/_search endpoint. This is the canonical Elasticsearch idiom for splitting one search into N sub-buckets, each with its own predicate, and we haven't found a workable equivalent using bool + terms.

Repro (ES-compat)

curl -sS -X POST "$QW/api/v1/_elastic/<index>/_search" \
  -H 'content-type: application/json' \
  -d '{
    "size": 0,
    "aggs": {
      "failed_logins": {
        "filter": { "term": { "event.outcome": "failure" } },
        "aggs": { "c": { "value_count": { "field": "@timestamp" } } }
      }
    }
  }'

Observed behavior

HTTP 400 — agg parser rejects the filter key. Same shape on filters. Reproduces regardless of the inner query (term, bool, query_string, match_all).

Expected behavior

Accept filter and filters with standard Elasticsearch semantics: bucket the matching docs, run sub-aggs only on that subset.

Use case

Stacked-series dashboards where multiple metrics share the same date_histogram axis but each has its own predicate (e.g. "failed logins per hour" alongside "successful logins per hour" on one chart). The only purely-Quickwit alternative is N round-trips, which doesn't compose for shared axes.

Version

Observed on 0.8.x. Have not verified against main — happy to retest if this is already fixed.

Reproduce the request against both the native search API and the ES-compat _elastic/_search endpoint, then trace the aggregation parser entry point for bucket aggregations. Implement support for filter and filters with sub-aggregations and verify that both forms apply their predicates to the correct document subsets, including the supplied value_count example.