Always send an explicit LIMIT on BanyanDB queries (#13961)

BanyanDB applies its own default limit to any query that carries none --
100 rows for measures, 20 for streams/traces -- and applies it after
GROUP BY, so an over-long result set is silently truncated rather than
rejected.

OAP never sent a limit on several read paths, so an entity-scoped metrics
query returned at most 100 data points regardless of the requested range:
a 4-hour minute-step read rendered only its first 100 minutes and the rest
showed as empty, even though DurationUtils.MAX_TIME_RANGE allows up to 500
steps. The same cap silently shortened topology relation maps, instance
and process metadata lists, profiling thread snapshots and eBPF task lists.

Every BydbQL query now leaves OAP with an explicit LIMIT:

- the entity-scoped metrics read sends the exact number of assembled
  duration points, the same row set the ES/JDBC DAOs fetch by explicit id;
- ad-hoc SELECT TOP sends its own N;
- anything that does not paginate itself falls back to the configured
  resultWindowMaxSize (default 10000) via Conditions#limitIfAbsent, applied
  in the stream/measure/trace query helpers that every DAO funnels through.

The fallback is spliced in at the start of the pagination tail rather than
appended, so it lands ahead of an OFFSET that was set first and keeps
WITH QUERY_TRACE positioned as the grammar requires.

ES and JDBC storage were never affected -- both fetch metrics rows by
explicit document id.