epic(ui): SQL workspace in one visual system and with fewer control rows

The issue names sql_workspace_toolbar.dart and sql_query_tab_bar.dart; start by reading those files and the SQL pane’s editor, result bar, and workbench decoration code. The issue proposes two stages, with stage 1 covering shared surfaces, icons, button styles, and responsive labels, then stage 2 changing the layout and editor sizing. Done means satisfying the listed acceptance criteria, including widget and guard tests plus before and after screenshots in both themes.

Why

The SQL workspace is the screen people spend most of their time on, and it is the least consistent one: five control rows around the editor and the grid, three different surface treatments, two different icon-button looks in one toolbar, the same state shown in several places. This issue collects what a visual review of current dev (0.4.22+5, Linux, Demo Playground, 1028 px window, dark theme) found, with measurements, and proposes one target layout. Items are meant to be split into PRs.

What was measured (logical px, from a screenshot of the running app)

Five control rows = ~209 px before any data. On a 1366x768 laptop that is ~27% of the window height; the one-line query above gets an editor of ~672 px while the grid beneath shows 8 rows.

Findings

1. Vertical budget

• The editor is given 65% of the pane regardless of content. A one-line query leaves a large empty card and a grid squeezed to the bottom.
• Five control rows (see above), and the status bar repeats part of them (item 4).

2. Three surface languages in one pane

• Editor: SqlEditorChrome, radius 14, 1 px accent-tinted border, accent glow (blurRadius: 28) from workbench tokens.
• Toolbar: sqlToolbarDecoration, flat strip, workbench.surface at 0.85 alpha, hairline bottom border.
• Tab strip (sql_query_tab_bar.dart): Theme.of(context).colorScheme.card / .border, i.e. shadcn tokens, not workbench tokens (also relevant for #1465).
• Results: no container at all.
  A card with a glow above flat bars and a bare grid reads as three unrelated components.

3. Toolbar (sql_workspace_toolbar.dart)

• Same icon for two different things: Explain uses Icons.account_tree_outlined, and the Diagram button in the tab strip uses the same icon. At the default width Explain is icon-only, so the two are indistinguishable.
• Two looks of icon buttons in one row: Explain and Session are bordered, History / Format / Open / Save are borderless.
• The Auto-commit badge is a tiny pill next to 36 px buttons, and the Session menu's label says Session · auto-commit: the same state twice (badge + menu label).
• compact is decided on the toolbar's own width (< 900), which is the window minus the sidebar. With the default sidebar the toolbar is compact in a 1028 px window, so the labels (Execute (F5), Explain) are never shown on a normal laptop.

4. The same information in several places

• Row count and elapsed time: result mode bar (12 row(s)., 1 ms) and the status bar (1 ms, 12 rows, 8 cols). The wording differs (row(s) vs rows).
• Connection name and path: sidebar item, header (SQLite), status bar.

5. Staged-changes row always visible

• Add Row / Delete Row / No changes / Save Changes takes a full row even when nothing is staged and nothing is dirty. It can live in the result mode bar (or appear only once the grid is in edit mode).

6. Related defects found in the same pass

• Status bar stuck on Running query…: see the bug filed separately.
• Raw duplicated exception dump as the error view: see the separate issue.

Proposal

Two stages; stage 1 is cheap and removes the inconsistencies, stage 2 reclaims ~90 px.

Stage 1: one visual system (no layout change)

• One surface rule for the pane: bars use workbench.surface + hairline border; the editor and the results are both framed the same way (same radius, no glow on the editor, or glow on both). Drop the accent glow from the editor card or move it to focus state only.
• Tab strip on workbench tokens (no Theme.of(context).colorScheme in the SQL pane).
• Toolbar: one icon-button style (ghost, md), distinct icons (Explain: a plan / magnifier-with-lines icon; Diagram keeps the tree), the Auto-commit badge at control height or folded into the Session menu label only.
• compact from the window or from a measured threshold per control (labels collapse one by one), not from the content width.
• One wording and one place for counts: 12 rows in the status bar only, the result bar keeps only what is not elsewhere (time of the shown tab, truncation notice).

Stage 2: fewer rows

• Put the run controls on the right of the query tab strip (tabs left, Run / Explain / History / Format / Open / Save / Session right): the toolbar row goes away (-50 px). Overflow into a ... menu below ~700 px.
• Merge the staged-changes actions into the result mode bar and show them only while the result is editable (-41 px).
• Auto-fit the editor: height = lines of text clamped to 120..40% of the pane, the user's splitter position wins once dragged and is remembered per tab.

Sketch of the target:

SQLite   Overview | SQL
Query 1 | Query 2 | +              [> Run v] [Explain] [History] [Format] [Open] [Save] [... Session]
+---------------------------------------------------------------+
| SELECT * FROM orders LIMIT 200;                               |   <- auto-fit, min 120 px
+---------------------------------------------------------------+
Grid | Groupings | Charts     [filter] [eye] [{}]   +Row -Row  Save changes   Export v  Save File v
id | user_id | product_id | ...                                      

Acceptance

• Stage 1: no Theme.of(context).colorScheme and no raw Color(0x...) in the SQL workspace files; one border radius and one surface rule for editor, toolbar, tab strip and results (add a widget test that reads the decorations).
• Stage 1: Explain and Diagram have different icons; all icon buttons in the toolbar share one style and height (extend test/guards like button_standard_guards_test.dart).
• Stage 1: the toolbar keeps its labels at 1028 px window width with the sidebar open, or collapses control by control.
• Stage 2: control rows above the grid: 3 (header, tabs+actions, result bar); measured heights are listed in the PR.
• Stage 2: a one-line query gets a ~120 px editor; the splitter position survives re-runs and tab switches.
• A screenshot pair (before / after) in the PR for dark and light themes.

Related: #1331, #1465, #1480, #1336 (UI kit gallery), #1340 (height tests); closed predecessor #1150 (one-row toolbar).