fix(aggs): the columnar histogram paths honour config.limits.max_buckets - #125

…121)

`fast_aggs::exec_terms` built its term map with no bucket cap of any kind,
only a `size`-derived OUTPUT cap. An operator who lowered
`config.limits.max_buckets` to protect memory got that protection only on
queries that missed the columnar path: measured at max_buckets=37 over 200
distinct terms, the fast path (a 12k-doc index) materialised all 200
(top5=300 + sum_other_doc_count=11,700) while the brute `run_terms` stopped
at 37. That is the OOM vector the cap exists to close — the half PR #125
left open after fixing the histogram executors.

The two executors must AGREE past the cap. Brute `run_terms` does not error
there; it keeps the first `max_buckets` distinct terms in doc-iteration
order, drops the rest, and reports a `sum_other_doc_count` computed only
over the terms it kept, so the dropped terms vanish silently and the total
conceals them (order-dependent). Mirroring that truncation onto the fast
path would copy the bug, not the contract; erroring would make the fast
path disagree with a brute path that still returns a body.

So `exec_terms` BAILS to brute the moment its distinct-term count would
exceed the cap, checked as the map grows (per segment and after the
memtable) so the map is bounded to ~`max_buckets`. After the bail the
request is answered by the very `run_terms` a test measures the fast path
against, so the two AGREE past the cap by construction — the same shape as
the #104 / #120 bail-to-brute fallbacks. An index whose distinct count is
at or under the cap is served columnarly as before, and the default-cap
(65,536) common case is untouched.

Test (its own binary, one function, like agg_bucket_cap.rs, because the cap
lives in a process-wide static): a 10,050-doc index over 200 terms at cap 37
is no longer served columnarly (`fast_path_aggs_served` does not tick) and
honours the cap (37 buckets, not 200); a 600-doc brute index of the same
shape agrees on the count; and an at-cap index (exactly 37 terms) is still
served columnarly, guarding against over-bailing. Reverting only
fast_aggs.rs fails it: served==1, 200 buckets against max_buckets=37.

…brute (#134)

* fix(aggs): the columnar terms path honours config.limits.max_buckets (#121)

`fast_aggs::exec_terms` built its term map with no bucket cap of any kind,
only a `size`-derived OUTPUT cap. An operator who lowered
`config.limits.max_buckets` to protect memory got that protection only on
queries that missed the columnar path: measured at max_buckets=37 over 200
distinct terms, the fast path (a 12k-doc index) materialised all 200
(top5=300 + sum_other_doc_count=11,700) while the brute `run_terms` stopped
at 37. That is the OOM vector the cap exists to close — the half PR #125
left open after fixing the histogram executors.

The two executors must AGREE past the cap. Brute `run_terms` does not error
there; it keeps the first `max_buckets` distinct terms in doc-iteration
order, drops the rest, and reports a `sum_other_doc_count` computed only
over the terms it kept, so the dropped terms vanish silently and the total
conceals them (order-dependent). Mirroring that truncation onto the fast
path would copy the bug, not the contract; erroring would make the fast
path disagree with a brute path that still returns a body.

So `exec_terms` BAILS to brute the moment its distinct-term count would
exceed the cap, checked as the map grows (per segment and after the
memtable) so the map is bounded to ~`max_buckets`. After the bail the
request is answered by the very `run_terms` a test measures the fast path
against, so the two AGREE past the cap by construction — the same shape as
the #104 / #120 bail-to-brute fallbacks. An index whose distinct count is
at or under the cap is served columnarly as before, and the default-cap
(65,536) common case is untouched.

Test (its own binary, one function, like agg_bucket_cap.rs, because the cap
lives in a process-wide static): a 10,050-doc index over 200 terms at cap 37
is no longer served columnarly (`fast_path_aggs_served` does not tick) and
honours the cap (37 buckets, not 200); a 600-doc brute index of the same
shape agrees on the count; and an at-cap index (exactly 37 terms) is still
served columnarly, guarding against over-bailing. Reverting only
fast_aggs.rs fails it: served==1, 200 buckets against max_buckets=37.

* doc(aggs): drop the now-false exec_terms 'no bucket cap' note

This PR gives exec_terms a bucket cap, so the FAST_PATH_AGGS_SERVED comment
that cited it as a still-uncapped divergence is now false. Replaced with the
current list (#99/#104/#114/#120 closed, #128 nested-object still open).