Row-count display on a filtered view shouldn't force a full COUNT(*) on
every list fetch. New endpoint returns either an EXPLAIN-plan estimate
(default, ~1ms, no execution) or a LIMIT-capped exact count that short-
circuits to `{ capped: true }` once the match set passes EXACT_COUNT_CAP.
Clients call it in parallel with the rows query so the grid still paints
at its own pace.
- DTO + repo.countEstimate/countExact reusing the list predicate shape
- service picks the mode; controller mirrors the list Read ability check
- client hook keyed by filter/search/exact so a "show exact" toggle
doesn't clobber the estimate cache
The view-draft layer stores `{op: 'and', children: []}` as an explicit
"override baseline with no predicates" marker. That payload was leaking
into /bases/rows requests once local filter/sort drafts were enabled —
harmless server-side (buildWhere maps an empty group to TRUE) but it
destabilised the React Query key and cluttered request payloads. Normalise
empty groups to undefined at the hook level.
Philipinho