feat: chart-type-aware row cap — chartRowCap(type) replaces flat CHART_ROW_CAP=500

[BorisTyshkevich]

What & why

Closes #109

CHART_ROW_CAP was one flat constant (500) applied to every chart type. Each shape has a different readable ceiling:

• Pie legibility tops out around 20-30 slices regardless of monitor width.
• Bar/column are bound by minimum bar+gap width for legible category ticks.
• Line/area are point-density bound — a wide canvas can plot thousands of points before individual ones blur together (the report that prompted Chart-type-aware row cap: chartRowCap(type) replaces flat CHART_ROW_CAP=500 #109: a 1.4K-row result only plotted its first 500 points on a line chart).

CHART_ROW_CAPS / chartRowCap(type) in src/core/chart-data.js replace the constant: { pie: 30, hbar: 500, bar: 1000, line: 5000, area: 5000 }, falling back to 500 for an unmapped type. buildChartData() and the results.js truncation note both key off cfg.type; switching chart type re-slices and updates the note via the existing rerender() path (no new plumbing needed there).

Out of scope (tracked separately in #111, referenced in #109's body): buildChartData() slices raw rows before aggregating, which is a correctness issue for un-pre-aggregated results, not a readability one — different fix shape, kept out of this same-day pure-lookup change.

Verification

• npm test — full 100/100/100/100 gate on chart-data.js, updated tests in results.js.
• npm run test:e2e — 26 passed (Chromium + WebKit clean); 13 Firefox failures are all pre-existing unshare(CLONE_NEWPID): EPERM sandbox errors in beforeEach (an environment limitation of this container), none touching chart code.
• Manual verify against a live ClickHouse (26.3.10, antalya demo cluster) via npm run local + Playwright: ran a 2000-row query, cycled every chart type, confirmed the note and plotted-point count for each: Bar first 500 of 2.0K rows, Pie first 30 of 2.0K rows (visually ~30 legible slices), Column first 1000 of 2.0K rows, Line/Area — no truncation (2000 < 5000 cap).
• /code-review (5 parallel finder angles + verify): one confirmed finding — a stale docstring on chartRowCap claiming the fallback was "the bar/column default" when it's actually 500 (hbar's value, not bar's 1000) — fixed in this PR.

Checklist

• npm test passes (the per-file coverage gate is non-negotiable)
• Tests added/updated in the same change as the code
• npm run build succeeds (single-file dist/sql.html)
• 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
• Reconciled affected tracked work — Chart-type-aware row cap: chartRowCap(type) replaces flat CHART_ROW_CAP=500 #109 isn't part of the Roadmap to 1.0.0 #68 roadmap phases (standalone enhancement); no ADR touched; Chart aggregation sums only a truncated prefix of fetched rows, and the note overstates what the chart represents #111 (the follow-up correctness issue it explicitly scopes out) left untouched

🤖 Generated with Claude Code

https://claude.ai/code/session_01784dKCpk5W7rdpUAwcQnix