[SS] Add drill-to-detail from Dashboard charts and tables

Summary

Add Superset-style drill-to-detail so an analyst can open the contributing rows behind a chart mark, table cell, KPI, or selected Dashboard context without manually reconstructing the filters in SQL.

The feature must remain SQL-first and explicit. It should reuse saved queries, typed parameters, current Dashboard filter state, and the shared result-table/cell-detail surfaces. Do not attempt arbitrary SQL AST rewriting of an existing aggregation query.

User value

From a Dashboard, an analyst should be able to answer:

• Which rows contributed to this bar or point?
• Which records make up this KPI?
• What is behind this grouped value?

The action should preserve the current Dashboard context and open a detailed, inspectable table in the Workbench or an equivalent dedicated detail surface.

Authoring contract

A tile may explicitly declare a drill target:

• a saved detail query id;
• mappings from one or more raw result columns to the detail query's typed parameters;
• whether current Dashboard filters are also forwarded;
• optional title/label metadata.

Do not infer a detail query from table names, display labels, or the aggregation SQL.

The detail query remains an ordinary saved query. It owns SQL, parameter declarations, optional blocks, presentation, and export behavior. Drill metadata only defines how the source context supplies parameter values.

Interaction semantics

• Expose a View contributing rows action from eligible chart marks, table rows/cells, KPI cards, and accessible context menus.
• Use raw values, not formatted labels.
• Preserve the current Dashboard filter values and active state when configured.
• Apply source-mark values after the Dashboard context so explicit drill mappings have deterministic precedence.
• Validate the complete parameter set before opening or running the detail query.
• On invalid, missing, ambiguous, or incompatible mappings, open nothing and surface a clear diagnostic.
• The source Dashboard remains unchanged.
• Keyboard users must be able to invoke the same action from focused eligible content.

Destination behavior

Preferred v1 flow:

1. Create/open a Workbench tab linked to the authored detail saved query.
2. Seed its typed parameter controls from the resolved Dashboard and mark context.
3. Run once after successful validation.
4. Show the ordinary full result table with existing sorting, cell detail, copy, and export behavior.
5. Make the origin clear in the tab title or a compact context note.

Repeated drills may reuse an existing matching detail tab only when doing so cannot overwrite unrelated unsaved edits. Otherwise open a new tab.

The operation must not modify the saved detail query, source query, Dashboard document, workspace revision, or persisted default parameter values merely by opening the drill.

Scope and security

• Values must flow through ClickHouse native typed parameters; never interpolate literals into SQL.
• Respect the current authenticated ClickHouse connection and server-side authorization.
• Reuse optional filter-block semantics for omitted optional values.
• Do not expose columns or queries the current user cannot execute.
• Preserve cancellation and stale-result protection if a newer drill supersedes an in-flight auto-run in the same destination.

Supported sources for v1

• discrete bars/columns;
• line/area points;
• pie slices;
• table rows and cells;
• KPI cards with explicit mapping metadata.

Time-range brushing is not itself a drill mark, but the active time-range filters should be forwarded as Dashboard context when configured.

Tests

Cover:

• raw mark values versus formatted labels;
• one and multiple mapped dimensions;
• current Dashboard filters forwarded with correct active state;
• deterministic precedence between Dashboard context and mark mappings;
• optional parameters omitted safely;
• unknown/duplicate/incompatible mappings fail before opening/running;
• chart, table, and KPI source actions;
• destination tab creation without overwriting unsaved tabs;
• exactly one validated execution;
• cancellation/stale result behavior for repeated drills;
• source Dashboard and persisted workspace remain unchanged;
• keyboard invocation and accessible labels;
• Chromium, Firefox, and WebKit.

Acceptance criteria

• A tile can explicitly reference an ordinary saved query as its detail target.
• Eligible marks/rows expose an accessible View contributing rows action.
• Raw source values and current Dashboard filters are mapped to typed detail-query parameters.
• Invalid mappings or values perform no partial navigation or execution.
• The detail query opens in a safe Workbench tab and runs once.
• Source and destination saved documents remain unchanged by the drill action.
• Existing result-table inspection and export features work on the detail result.
• Unit and real-browser tests pass.

Non-goals

• automatically rewriting arbitrary aggregate SQL into row-level SQL;
• database-level lineage inference;
• semantic joins between datasets;
• drill-by/group-by selection;
• nested breadcrumb/history navigation;
• a modal mini-table that duplicates the Workbench result surface;
• bypassing ClickHouse authorization.

Start by tracing the Dashboard chart, table, and KPI action entry points, then follow the Workbench tab, typed-parameter, and shared result-table flows described in the issue. Run the relevant unit and Chromium, Firefox, and WebKit tests; done means validated drills open a safe detail tab, execute once, preserve context, and leave source documents unchanged.