Rename surviving filter terminology to Dashboard variables

[BorisTyshkevich]

Found while shipping #447 phase 1. The curated-filter model is gone, but surviving runtime, UI and CSS identifiers still use filter for concepts that now represent inferred Dashboard variables.

This issue is terminology-only. It must not change behaviour.

Runtime and API renames

Rename the surviving variable runtime types and fields:

• ViewerFilterState, ViewerFilterStatus, ViewerFilterOption, FilterRuntime
• DashboardViewState.filters / filterDiagnostics
• setFilter, applyFilter, applyFilters, clearFilter, clearAllFilters, resetFilters, getFilterField
• DashboardTimeRangeGroup.fromFilterId / .toFilterId
• TimeRangePairCandidate.fromFilterId / .toFilterId
• src/ui/filter-bar.ts, FilterBarHandle, FilterBarApp
• src/core/filter-width.ts

Use names that describe Dashboard variables rather than the removed curated-filter model.

UI, CSS and fixtures

Rename the remaining filter-oriented selectors and update their consumers together:

• .dash-filters
• .dash-filter-host
• .dash-filter-time
• .dash-filter-ordinary
• .dash-clear-filters
• .dash-filter-diagnostics

The time-range and mobile E2E fixtures use several of these names and must move in the same change.

Rename .ms-overlay, which survives only as src/ui/popover.ts's default overlayClassName and in the time-range E2E selector. The ms- prefix came from the deleted multi-select control.

Persisted and interchange exceptions

Do not rename asb:dashFilters without a real migration. Changing that key silently discards saved Dashboard variable values. Either:

• keep the persisted key and document why its historical name remains, or
• add an explicit migration that preserves all values.

Do not rename identifiers that belong to read-only legacy interchange schemas merely for consistency. dashboard-v1 must continue describing curated filters while v1 bundles and stored-workspace v2/v3/v4 records remain supported.

Acceptance

• No surviving runtime, source filename or CSS identifier names the removed curated-filter concept, except documented persisted/interchange compatibility exceptions.
• Existing values under asb:dashFilters survive the upgrade.
• No behaviour changes.
• npm test, npm run check:arch, and npm run test:e2e on Chromium and WebKit stay green.

Split from #457. Related to #447 phase 2.

[BorisTyshkevich]

Ship log — #459

Single-phase issue (no ## Phases section) — shipped whole in one PR off main.

Phase	Status	PR
1 — whole issue: rename surviving filter terminology to Dashboard variables	in review	#474

Handoff

Landed (branch refactor/variable-terminology-459)

• Runtime/API: ViewerFilterState/ViewerFilterStatus/ViewerFilterOption/
  FilterRuntime → ViewerVariableState/…Status/…Option/VariableRuntime;
  ApplyFiltersResult → ApplyVariablesResult;
  DashboardViewState.filters → .variableStates (deliberately distinct from
  the pre-existing .variables, which is every inferred variable including
  conflicted/orphaned; variableStates is the bindable-with-a-runtime subset);
  .filterDiagnostics → .optionDiagnostics (it is the BATCH-level
  option-query report); .resettableFilterIds/.activeFilterCount →
  .resettableVariableIds/.activeVariableCount;
  setFilter/applyFilter/applyFilters/clearFilter/clearAllFilters/
  resetFilters/getFilterField → the …Variable(s) forms; resolveFilterTargets
  → resolveVariableTargets; deps.initialFilters → deps.initialVariables;
  NO_FILTER_DIAGNOSTICS → NO_OPTION_DIAGNOSTICS.
• Time range: DashboardTimeRangeGroup/TimeRangePairCandidate
.fromFilterId/.toFilterId → .fromVariableId/.toVariableId;
  filterTargetTileIds → variableTargetTileIds; diagnostic code
  'time-range-filter-unresolved' → 'time-range-variable-unresolved'
  (verified absent from schemas/** and src/generated/** — runtime-only).
• Files: ui/filter-bar.ts → ui/variable-bar.ts, ui/filter-option-field.ts →
  ui/variable-option-field.ts, core/filter-width.ts → core/variable-width.ts,
  dashboard/model/dashboard-filter-store.ts → dashboard-variable-store.ts
  (+ the four matching unit specs). Exports moved with them
  (buildVariableBar, VariableBarHandle/VariableBarApp/BuildVariableBarOptions,
  VARIABLE_DEBOUNCE_MS, VariableBarComboField, buildVariableOptionField,
  VariableOptionField/VariableOptionFieldOpts, variableWidthCategory/
  VariableWidthCategory/variableInputWidthCh, DashboardVariableEntry/
  DashboardVariableBag/AllDashboardVariables, read/writeDashboardVariableBag,
  variableBagSignature).
• CSS: .dash-filters→.dash-variables, .dash-filter-host→.dash-variable-host,
  .dash-time-filter-host→.dash-time-variable-host,
  .dash-filter-time→.dash-variable-time,
  .dash-filter-ordinary→.dash-variable-ordinary,
  .dash-clear-filters→.dash-clear-variables,
  .dash-filter-diagnostics→.dash-variable-diagnostics,
  .dash-toolbar-filters→.dash-toolbar-variables,
  .detached-filter-row→.detached-variable-row, .has-filters→.has-variables,
  .filter-select→.variable-select, .ms-overlay→**.popover-overlay**.
• e2e fixtures + specs moved in the same change (dashboard-mobile.{html,spec.js},
  time-range.{html,spec.js}, multi-select.spec.js,
  workbench-var-strip.spec.js).

Decisions taken (recorded in the ADR-0003 #459 addendum, not just here)

1. asb:dashFilters kept, not migrated. The issue offered keep-and-document
   or migrate-with-full-preservation. Chose keep: the key holds real committed
   values on users' machines, renaming it discards them silently on the next load,
   and a read-old/write-new migration is a behaviour change inside a change whose
   whole contract is "no behaviour change". The property name still matches the key
   string so the two cannot drift. Documented at KEYS.dashFilters (state.ts)
   and in the store's header.
2. The filterActive family is out of scope, on purpose. state.filterActive
   / asb:filterActive / saveFilterActive / effectiveFilterActive name the
   WORKBENCH's optional-/*[ ]*/-block activation — a live concept that is not a
   Dashboard variable — and are persisted besides. Documented at
   KEYS.filterActive. A future rename would need its own issue + migration.
3. Legacy interchange untouched. DashboardFilterDefinitionV1,
   dashboardFilterDefinitionV1, DashboardDocumentV1.filters,
   dropCuratedFilters, PORTABLE_LIMITS history: dashboard-v1 must keep
   describing curated filters. schemas/** and src/generated/** have zero
   diff.
4. User-observable text moved too — the only perceivable half of the rename.
   Visible section label Filters → Variables; aria-labels
   Dashboard filters/Dashboard time filters/Query filters → the variables
   forms; multi-select trigger "<name> filter, N selected" →
   "<name> variable, N selected"; two batch-error strings
   (The variable batch contains an unknown or duplicate variable.,
   … is not a valid variable value.). Rationale: the Dashboards tree has said
   "Variables" since Replace curated Dashboard filters with inferred Variables and batched option queries #447 phase 1, so leaving the most visible old vocabulary
   while renaming every hidden one would widen the inconsistency.

Deviations from the spec: none. The issue's rename list is fully covered, plus
the identifiers it did not enumerate but its acceptance criterion 1 requires
(.filter-select, FilterBarComboField, NO_FILTER_DIAGNOSTICS,
filterTargetTileIds, dashboard-filter-store.ts, filter-option-field.ts,
resettableFilterIds, activeFilterCount, the ui/dashboard.ts locals).

Falsifiability — the point that needed real work. A pure rename passes its
suite whether or not it is right, and every existing persistence test reached the
storage key through the KEYS constant, so changing the key's value would have
left 5600 tests green while orphaning real data. Added three guards, all
sabotage-checked (each verified to fail when its subject is reverted):

• tests/unit/state.test.ts — pins every KEYS literal string, including both
  documented "filter" exceptions;
• tests/unit/dashboard.test.ts — pins the two Dashboard group aria-labels,
  which nothing asserted before;
• tests/unit/dashboard-viewer-session.test.ts — pins the batch rejection
  message, which reaches a screen reader via variableRefreshLiveEl.

Also added src/ui/variable-bar.ts to typography-contract.test.js's source
list. It builds the Dashboard's and the detached view's {name:Type} rows —
markup the already-gated dashboard.ts delegates rather than renders — so it
sat outside that gate for exactly the carved-out-markup failure mode the test's
own comment opens with. Without it an emitter/rule drift on a class like
.dash-variable-time was undetectable. It passes as-is.

Persistence safety was additionally proven against main directly rather than by
trusting the new comments: all 46 executable lines of the store are identical
modulo the rename, bag[f.id] still keys stored entries by the variable name with
the same value/active fields, and the read path (deps.initialVariables[name],
id: name) matches the write path.

Review findings applied (second commit b6042af) — worth knowing, because one
was a real defect a rename script will reproduce next time:

• multi-select-field.ts's local applyFilter() is the popover's search-box ROW
  filter — a genuine filter and exactly the class the exception list protects. The
  word-boundary script renamed it to applyVariable() anyway, contradicting its
  own comment and colliding by name with session.applyVariable referenced in the
  same file. Now applySearchFilter(). Lesson: a scripted rename of a generic
  verb+noun like applyFilter needs a per-file allowlist, not just a
  word-boundary regex.
• The .ms-overlay rationale I first wrote was factually wrong ("the last trace of
  the deleted multi-select control's prefix"). Restore the searchable multi-select for Array(scalar T) Dashboard variables with option SQL #468 restored that control and its
  fourteen ms-* classes are alive; the rename is still right because that class
  is the shared ui/popover.ts primitive's default backdrop, never
  multi-select-specific. The issue's own premise for this bullet is stale post-Restore the searchable multi-select for Array(scalar T) Dashboard variables with option SQL #468.
• "dashboard filter bar" had survived as the component's NAME across the whole
  shared field family (param-pipeline.ts, enum-field.ts, combobox.ts,
  relative-time-field.ts, recent-field.ts, time-range-field.ts,
  var-field.ts, core/dashboard.ts, ui/app.ts) — so the dominant phrase for
  the thing was still the old one. Two of those had the module specifier updated
  but not the noun beside it.
• file-menu.ts's import-replace confirmation told the user it replaces "tiles,
  layout, and filters"; a v2 Dashboard has had none since Replace curated Dashboard filters with inferred Variables and batched option queries #447.
• ui/dashboard.ts:541 claimed present-tense that it merges "explicit +
  synthesized implicit filters" — false since Replace curated Dashboard filters with inferred Variables and batched option queries #447.
• An ADR typo recorded the rename target as from, a field that does not exist.
• Two callback locals survived at ui/dashboard.ts:752
  ((filter) => !ordinaryTimeIds.has(filter.id)): the script only matched
  callbacks whose body STARTED with filter., so a chained predicate slipped
  through. Third commit 33f5476.

Verification: npm test 5603 passed (100/100/100/100 per-file gate held),
tsc --noEmit clean, npm run check:arch clean, npm run build clean,
npm run test:e2e 366 passed on chromium + firefox + webkit, and a real-browser
check of the live Dashboard (renamed classes keep their computed styles — scroll
host overflow-x: auto/nowrap, Clear all keeps its radius/type/colour — the row
label renders "VARIABLES", accessible names read "Dashboard variables", no stale
.dash-filter*/.ms-overlay/.filter-select nodes, no console errors).

Follow-ups filed: #478 (inbox) — the shared VariableBarApp port declares
state.filterActive/params.saveFilterActive, and the Dashboard satisfies it with
a local draftActive map + a NO-OP save, so one of the port's two callers has
nothing persisted behind that name. My first rationale for the exception ("not a
Dashboard variable at all") was wrong and is corrected in the ADR + CHANGELOG; the
exception itself stands on the narrower argument that the name denotes
optional-/*[ ]*/-block activation, a live concept. Not folded in because params
is a Pick<WorkbenchParameterSession, …> and the bar mutates the caller's map IN
PLACE before calling saveFilterActive() — an adapter that copies rather than
aliases would silently stop persisting activation in the detached view, and no test
today would fail. #478 requires that write-through test either way.

Also #473 (inbox) — the mobile e2e fixture asserts a
.has-variables toolbar class the app never sets, and the CSS rule its comment
claimed never existed; corrected the comment here and deferred the
fixture/contract decision.

Reconciled: ADR-0003 — the #447 "deliberately deferred" bullet is marked spent
(its pre-#459 names kept verbatim as the record of what was deferred) and a #459
addendum added; CHANGELOG.md [Unreleased] → Changed; README terminology for the
Dashboard variable row (the Workbench's "optional filter blocks" feature keeps its
own, correct, name). #459 is not tracked on the roadmap meta-issue #68, so nothing
to re-scope there.