[SS] Add Dashboard cross-filtering from chart and table selections

Summary

Add Superset-style cross-filtering so an analyst can click a chart mark or table value and use that exact underlying value as a Dashboard filter for other tiles.

This should extend the typed Dashboard filter/execution architecture already used by manual filters and synchronized time-range brushing. It must not introduce a second ad hoc filtering path or interpolate values into SQL.

User value

Analysts should be able to move from viewing a dashboard to asking a follow-up question without leaving the page:

1. Click a bar, point, slice, legend value, or eligible table cell.
2. See the corresponding Dashboard filter update immediately.
3. Rerun only the affected tiles once.
4. Click again, use the filter bar, or use an accessible action to change/clear the selection.

Authoring contract

Cross-filter behavior must be explicitly authored and portable. Do not infer targets from display labels.

Use saved-query/panel metadata that maps:

• an exact raw result-column name;
• to a query parameter name;
• with optional interaction behavior such as replace versus toggle.

The Dashboard resolves the parameter to exactly one compatible filter definition. Ambiguous, missing, or type-incompatible mappings must fail closed with a visible diagnostic and leave the visualization non-interactive.

The contract should remain portable between Dashboards; avoid persisting a Dashboard-specific filter id in the saved query unless a tile-local override is used.

Interaction semantics

• Use the raw result value, never the formatted label.
• Plain click applies/replaces a scalar selection.
• Array-compatible filters may support additive/toggle selection through an explicit modifier or authored mode.
• A click on empty plot/background does nothing.
• A sub-threshold click must not conflict with chart brushing.
• Command/Ctrl-drag remains tile movement and must not trigger cross-filtering.
• Cross-filter state is visible and editable in the existing filter bar.
• Provide a keyboard-accessible equivalent action for focused marks/rows where the rendering surface supports it.
• Announce successful application or validation failure through the existing live region.

Execution semantics

• Resolve and validate the proposed value through the existing typed parameter pipeline.
• Commit filter state only after validation succeeds.
• Reserve affected tile generations synchronously before asynchronous preflight/source work.
• Cancel/supersede the previous affected wave once.
• Rerun each dependent tile once, including non-chart executable panels.
• Prevent stale results from the previous selection replacing newer results.
• Do not mutate saved queries, Dashboard documents, layout, workspace revision, or exported presentation data.

Supported surfaces for v1

• vertical and horizontal bars;
• line/area points where a discrete raw dimension value is available;
• pie slices;
• table cells;
• legend values when they correspond to an authored raw field.

Unsupported shapes must remain ordinary visualizations rather than guessing.

Visual state

• Show the active selected mark/value without replacing normal hover/tooltip behavior.
• Keep selections synchronized with external changes from the filter bar.
• Clear stale selected styling when a chart rerenders, a tile changes query/config, or the Dashboard route is destroyed.
• Multiple independent filters and interaction groups may coexist.

Tests

Cover:

• raw value versus formatted label;
• scalar replacement and array toggle behavior;
• unresolved/ambiguous/incompatible mappings;
• chart, pie, table, and legend sources;
• cross-filter plus existing manual filters;
• no conflict with time-range brushing or Command/Ctrl tile movement;
• one affected execution wave and one execution per dependent tile;
• stale-wave protection during rapid consecutive clicks;
• validation failure performs no partial mutation;
• external filter-bar changes update selected styling;
• route/rerender/destruction cleanup;
• light/dark themes and Chromium/Firefox/WebKit.

Acceptance criteria

• Authors can explicitly map a raw visualization field to a Dashboard filter parameter.
• Clicking an eligible mark/value applies the typed filter without SQL interpolation.
• The existing filter bar reflects and can edit/clear the selection.
• Only affected tiles rerun, exactly once per committed selection.
• Rapid selections cannot publish stale results.
• Ambiguous or invalid mappings fail closed with diagnostics.
• Time-range brushing, tooltips, and tile movement retain their current behavior.
• Unit and real-browser tests pass.

Non-goals

• automatic semantic joins between unrelated queries;
• guessing filter mappings from labels;
• arbitrary SQL rewriting;
• lasso/multi-mark selection;
• persistent bookmark state beyond the existing Dashboard filter-state mechanism;
• a full semantic dataset layer.

Beginne damit, die bestehende typisierte Dashboard-Filter-/Ausführungsarchitektur, manuellen Filter, synchronisierte Zeitbereichsauswahl per Brush, Filterleiste und unterstützten Darstellungsoberflächen für Diagramme/Tabellen nachzuverfolgen. Definiere den Abschluss anhand der genannten Anforderungen an Authoring, Validierung, Ausführung, Interaktion, Bereinigung und Tests im echten Browser, einschließlich einer betroffenen Ausführungswelle und des Schutzes vor veralteten Ergebnissen.