refactor(#359): one FilterSourceRuntime per unique Filter source query

[BorisTyshkevich]

What & why

Closes #359.

Dashboard filters that shared one Filter-source query rendered empty. The
viewer ran the source query once per filter definition and keyed each
provider by the filter-definition id, so mergeDashboardFilterHelpers saw N
identical providers for every helper name and rejected them all as
filter-duplicate-provider — and the explanatory diagnostics were silently
discarded. (examples/query-log-explorer.json hits this: user and
query_kind both point at qle-filter.)

This refactor splits the filter runtime into per-definition state and one
FilterSourceRuntime per unique sourceQueryId:

• the source SQL executes exactly once per refresh wave, no matter how many
  filters/parameters it feeds;
• the provider is keyed by the saved source-query id — two distinct
  sources providing the same helper still collide with no arbitrary winner;
• merge diagnostics (info/warning/error, severity preserved) are now
  published to the Dashboard instead of dropped;
• non-ready results clear curated options (no silent stale retention); an
  unresolvable sourceQueryId surfaces a visible source-error;
• an active value absent from refreshed options is deactivated (value kept)
  before dependent panels run;
• a per-filter optionsRev drives the filter-bar rebuild on option-content
  change (fixes non-empty → different-non-empty not updating the combobox);
• a superseded wave can no longer publish options/activation over a fresher
  one (stale-generation guard in the terminal merge step — found in self-review).

Per the issue's Settings ownership section, filterExecution no longer
injects readonly (server read-only policy belongs to ClickHouse user/profile
config, not feature code). Panel execution is unchanged. This establishes the
one-source-runtime boundary that #360 (parameterized sources + single-layer
dependency scheduling) builds on.

Scope / limitations

• The core merge (core/dashboard-filters.ts) is unchanged — the fix is in
  viewer source planning, state publication, and the UI rebuild/diagnostics.
• The added shared-source e2e is at the component granularity of the
  existing filter-source harness (two curated fields from one bundle rendering
  independently); no e2e harness in the repo mounts the full viewer session, so
  the "executes once / merge / dedup" behavior is covered by the unit suite.
• dashboard-viewer-session.ts branch coverage is ~94% (clears the enforced
  ≥90 floor); the uncovered branches are pre-existing defensive ones plus a few
  synchronous stale-gen entry guards that only a contrived concurrency race
  would exercise — the config's own note prefers this over artificial padding.

Checklist

• npm test passes (the per-file coverage gate is non-negotiable) — 157 files / 4421 tests
• 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
• README / CHANGELOG.md ([Unreleased]) updated if behavior or the deployed surface changed
• Reconciled affected tracked work (roadmap Roadmap to 1.0.0 #68 one-query-many-params note annotated with Refactor Dashboard Filter sources: execute once per source, preserve diagnostics, and reconcile option state #359/Allow Filter-role source queries to use root Dashboard parameters (single-layer dependencies) #360; CHANGELOG)

🤖 Generated with Claude Code

[BorisTyshkevich]

Review findings for 919defd59d76f2e8aa3a11aaaa6e9a9d843064d1:

1. P1 — CI is red in the newly added E2E. The e2e job fails on Chromium, Firefox, and WebKit in a shared Filter source renders curated values for all configured filters (#359). The harness mounts two independently constructed comboboxes from a hand-written object; it does not exercise FilterSourceRuntime, one-request deduplication, provider merging, diagnostics, option reconciliation, or the Dashboard viewer. Fix the test, replace it with a real viewer/session integration test, or remove the misleading E2E and rely on the substantive unit coverage.

2. P1 — a missing expected helper is still silent. In applyFilterProviders, when a source succeeds but omits a consumer's column, the filter becomes missing-helper and options are cleared, but no diagnostic is added. The Dashboard UI renders filterDiagnostics, not per-filter status, so users still see an empty/plain control with no explanation. Add a per-consumer filter-helper-missing diagnostic carrying sourceId and helperName, or visibly render the filter status next to the control.

3. P1 — persist each source's provider on FilterSourceRuntime. The implementation explicitly stores no provider and merges only providers returned by the current full wave. That leaves Refactor Dashboard Filter sources: execute once per source, preserve diagnostics, and reconcile option state #359 short of the source-runtime boundary needed by Allow Filter-role source queries to use root Dashboard parameters (single-layer dependencies) #360: changing one root parameter must rerun only affected Filter sources while retaining unaffected sources' helpers. Without a persisted provider per source, a selective wave cannot merge unchanged providers and would either clear unrelated filters or rerun every source. Add provider: FilterProvider | null, update it only for the current generation, and merge the complete provider set from all source runtimes.

What looks correct: one runtime per unique sourceQueryId, provider identity by saved query ID, strict real cross-source collision handling, source-owned cancellation/generation, terminal stale-wave guard, options-content revision, synchronous active-value reconciliation before affected panels, severity-preserving diagnostic publication, and removal of Filter-owned readonly injection.

I could not submit REQUEST_CHANGES because GitHub reports this is my own PR, so this is posted as a blocking review comment instead.

[BorisTyshkevich]

Re-review at a1c58cf37a245ff069cebf8ba8bb988c8727ebdf: approved from a code-review standpoint.

The three prior blockers are resolved:

1. The E2E now constructs a real DashboardViewerSession, exercises one-request source deduplication and provider merging, and CI passes across the browser matrix.
2. A source that omits an expected consumer column now publishes a visible filter-helper-missing diagnostic with sourceId and helperName.
3. FilterSourceRuntime now retains its generation-safe provider, and the terminal merge reads the complete provider set across all source runtimes, which is the correct boundary for Allow Filter-role source queries to use root Dashboard parameters (single-layer dependencies) #360 selective reruns.

I also rechecked the surrounding behavior: unique execution per sourceQueryId, strict collisions for distinct sources, generation/cancellation ownership, stale-wave protection, option-content revisions, synchronous active-value reconciliation before affected panels, severity-preserving diagnostics, explicit clearing on non-ready results, and removal of Filter-specific readonly injection all remain correct.

CI is green (ci and docker). No further blocking findings.