feat(search): graph search query endpoint with aggregations

[dschmidt]

This contains a huge libre-graph-api-go bump - so please don't be alarmed about the size of the diff

MS-Graph-style POST /graph/v1beta1/search/query with terms, range, metric and nested sub-aggregations, on both the bleve and OpenSearch backends.

Stacked on #3198.

Caveats

• Vendored libre-graph-api-go is interim, generated from feat: add search query endpoint with request examples libre-graph-api#34 rebased onto main. Proper path: land that spec PR upstream (feat: add search query endpoint with request examples libre-graph-api#34) and pin a released version.
• Aggregation behavior is pinned in the engine parity suite (AGG-01..09: term buckets, numeric and date ranges, open-ended bounds, metrics, malformed-bound errors), running against bleve and a real OpenSearch. That round also caught and fixed an OpenSearch bug: date range bounds were silently dropped, they now emit a date_range aggregation and malformed bounds are rejected on both engines. Nested sub-aggregations were smoke-tested end-to-end on bleve (artist -> album -> sum(duration)).

Note

Even once this PR and #3210 (honest has-preview + thumbnails relationship) are both merged, search hits still won't carry thumbnails — the $expand=thumbnails wiring for /search/query hits builds on both PRs and currently only exists on the consolidation branch (dschmidt/opencloud@feat/graph-search-full-2, commit 0d94199a: searchEntityThumbnailSet in searchquery.go, preview presence via thumbnail.HasPreviewForMimeType + indexed oc.preview/image-facet dimensions). It needs a follow-up PR once both are in.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 446 complexity

Metric	Results
Complexity	446

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[dschmidt]

Follow-up: narrow Fields when scanning hits for metrics / sub-aggregations

Not blocking, results are correct. It's the cost profile.

needsSubAggScan widens the page to subAggScanSize (math.MaxInt) for any
aggregation with sub-aggregations or a metric, since neither has a native facet
representation in bleve. Together with bleveReq.Fields = []string{"*"}, a
mediatype:image request carrying one Size/sum metric materialises the whole
matching hit set with every stored field, to add up one number. OpenSearch nests
natively and returns no documents.

Easy to reach from a client: a dashboard asking for a few library metrics over
mediatype:image pulls the whole image library into memory per load. Flat term
and range facets are unaffected.

Options by payoff:

1. Split scan from page. The scan needs only the metric and sub-agg fields; the
   rich Fields set only serves the PageSize window. One request cannot carry
   two field sets.
2. Otherwise narrow Fields to the union of what hydration and aggregations
   read, instead of "*".
3. Bound the scan, mark results approximate.
4. For real library counters (total bytes of all images), maintain a value at
   index time instead.

[dschmidt]

Follow-up: narrow Fields when scanning hits for metrics / sub-aggregations

Outdated: metrics and sub-aggregations are folded from doc values by aggCollector now (bleve/aggregations.go), hooked into the document-match handler. No page widening, no stored fields loaded for the scan; Fields: "*" only serves the page window.