feat(results): cap SELECT result rows (default 500) with a 100/500/1k/5k/10k selector

[BorisTyshkevich]

What & why

Closes #86 (Phase 2 of the roadmap #68).

A SELECT over a huge table used to pull every row over the wire (only the display was capped at 5000) — wasting bandwidth/memory and able to hang the tab. This adds a real fetch cap.

Hybrid mechanism (the settled design in #86):

• Server-side — max_result_rows = N + result_overflow_mode = 'break' so ClickHouse stops cleanly at the cap (no error, no full pull; it stops after the block that crosses N).
• Client-side guard — applyStreamLine trims the block-boundary overage break can leave and flags result.capped.

UX

• A 100 / 500 / 1000 / 5000 / 10000 selector in the result toolbar (after the view tabs; hidden for EXPLAIN views). Default 500.
• Global, persisted preference (one localStorage key, like theme/splitters) — applies to all tabs, survives reload.
• Changing it re-runs the current query with the new server-side cap, so raising it genuinely fetches more.
• A "first N (capped)" badge in the stats row when the cap is hit.
• The display grid now renders up to the selected cap (10000 actually shows 10000, not the old fixed 5000).
• EXPLAIN / PIPELINE / ESTIMATE are exempt (small output; a cap would truncate a plan oddly). The scope decision lives in app.js (it knows explainMode); ch-client just honors the caller's limit, since ESTIMATE also runs as Table and can't be told apart by format.

Files

• src/state.js — KEYS.resultRowLimit, resultRowLimit (default 500, from localStorage), RESULT_ROW_LIMIT_OPTIONS, pure normalizeRowLimit.
• src/net/ch-client.js — runQuery honors o.resultRowLimit via the existing extra dict.
• src/core/stream.js — newResult(fmt, rowLimit) carries the cap + capped; applyStreamLine stops at the cap. Pure, 100%.
• src/ui/results.js — selector, capped badge, visCap() display cap.
• src/ui/app.js — setResultRowLimit action; run path passes the cap for normal SELECTs only.

Checklist

• npm test passes (per-file 100/100/100/100 gate holds)
• Tests added/updated in the same change (state / stream / net / results / app)
• npm run build succeeds (single-file dist/sql.html, no new runtime dep)
• Layers kept honest: pure logic in src/core/, network in src/net/ (injected fetch), DOM in src/ui/
• No new runtime dependency
• CHANGELOG.md [Unreleased] updated (deployed HTTP surface unchanged — only query-string params added; no http_handlers.xml/README change)
• Reconciled tracked work: CHANGELOG done; ADR-0001 unaffected (resultRowLimit is a plain field like theme/density, not a signal); roadmap Roadmap to 1.0.0 #68 Phase-2 box to tick on merge

Verification

• Unit + integration: app.test.js exercises the real run() path — asserts max_result_rows/result_overflow_mode=break reach the URL for a normal SELECT, the client guard trims overage, capped is set, and EXPLAIN/ESTIMATE send no cap. results.test.js covers the selector (renders/reflects/re-runs), the badge, and visCap.
• e2e: npm run test:e2e green on Chromium / Firefox / WebKit (39 passed).
• A live browser verify (real ClickHouse + OAuth) wasn't run — no backend available in this environment; behavior is covered by the integration test above.

🤖 Generated with Claude Code