feat(results): page query results from the stats strip (#816)

[cevheri]

Closes #816. This supersedes #933 and #942, and both of their authors are co-authors on the commit.

Two people built this independently while I was slow to settle who had it, which is my fault and not theirs. Rather than pick a winner I took the design in #816 plus the seven review items on #942 and built it once, keeping what each of them got right. @DevvoLazza and @Dharshini-RS03 are credited in the commit and the squash will carry both trailers.

What was wrong

The starter query the object tree generated carried its own row bound, so applyQueryLimit returned it untouched and dropped the offset silently. prepareQuery still reported limit: 500 while the real bound in the statement was 50, so hasMore computed 50 === 500 and the control never rendered. Two defects hid each other: the control was missing, and because it was missing nobody ever triggered the dropped offset behind it.

What changed

The preview cap leaves the SQL text and travels as the limit execution option, so a user written LIMIT n means exactly one thing, a hard bound we do not page past. hasMore additionally requires prepared.wasLimited, because we can only offer page two of a bound this layer applied.

supportsResultPagination is declared by every provider in the repo, each value read from that provider's own prepareQuery rather than from a list. Twelve apply the offset. Cassandra and Elasticsearch refuse it, MongoDB and Redis pin it to zero, and LibreDB never sets wasLimited. The search provider declares this.product.acceptsOffsetClause, because one class serves two type-ids that differ exactly there: a literal true would offer a control that makes Elasticsearch throw, and a literal false would hide one OpenSearch can serve.

No chrome below the grid. LoadMoreFooter and its render site are gone. The former (more available) text in the stats strip is the control, reading 50 rows - load 50 more in the same text-xs font-mono language as its neighbours. The grid keeps its height whether or not another page exists, which the old footer did not.

An unordered query still paginates, and the grid says once, beside the auto-limited badge, that order across pages is not guaranteed. We do not inject an ORDER BY to avoid that.

Beyond the two documents

Three things neither the design nor the review named, found while mapping the code:

• src/app/api/db/transaction/route.ts computed the same hasMore and needed the same conjunct.
• src/lib/export/scope.ts reads hasMore to decide export truncation, so the export dialog was telling Cassandra and Elasticsearch users to load rows no control can load. The grid's three-way decision now lives in one place, pageOfferFor, and both the grid and the export scope read it.
• Clicking the control on a table whose row count is an exact multiple of the page size blanked the grid: the empty page returns fields: [] and the columns went with it. Found by driving the real UI, not by reading.

Verification

All gates run separately, each with its own exit code: format, lint, typecheck, knip, chart:check, channels:showcase:check, readme:check, security:check, test, build, build:lib, attw, test:coverage and coverage:check. 566 test files, 18694 passing, coverage 59259/59259 lines.

Not measured here: the twelve helm-chart-* test files, which need a built chart dependency, and the Go launcher checks. Every provider value was measured through prepareQuery against unconnected configurations rather than live engines, apart from PostgreSQL and SQLite, which were driven in a browser.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[cevheri]

Hi @Dharshini-RS03 and @DevvoLazza,
Do you have any suggestions or comments?

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud