e2e fixture asserts a `.has-variables` toolbar class the app never sets

[BorisTyshkevich]

Found while shipping #459 (terminology rename).

.has-variables (renamed from .has-filters in #459) is asserted by the
mobile Dashboard e2e fixture but never set by the app, and the CSS rule the
comment claimed for it has never existed.

Concretely:

• tests/e2e/dashboard-mobile.html:33 renders
  <div class="dash-toolbar dash-toolbar-variables has-variables">, and
  tests/e2e/dashboard-mobile.spec.js:182 / :269 locate the toolbar via
  .dash-toolbar.has-variables.
• src/ui/dashboard.ts:2328-2331 builds that toolbar with
  class: 'dash-toolbar dash-toolbar-variables' and hides it with an inline
  style: { display: 'none' } — it never adds a has-variables/has-filters
  class.
• src/styles.css has no .has-variables rule and never had a .has-filters
  one. Its comment above .dash-toolbar claimed the toolbar was
  "Hidden entirely (:not(.has-filters))"; Rename surviving filter terminology to Dashboard variables #459 corrected that comment to
  describe the inline display: none the code actually uses.

So the e2e fixture models markup the real app does not produce, and those two
specs pass against a hand-written class rather than the app's own contract. A
regression in how the toolbar is actually hidden (or shown) would not be caught.

Why deferred: #459 is terminology-only and must not change behaviour. Fixing
this means either teaching ui/dashboard.ts to set the class (a real markup
change) or re-fixturing the two specs to assert the inline-hidden contract — both
behaviour/test-contract decisions outside a rename.

Suggested fix: drop has-variables from the fixture and the two specs and assert
the toolbar's actual visibility contract (the inline display the app sets),
or decide the class is the intended contract and have ui/dashboard.ts set
it, replacing the inline style with a real :not(.has-variables) rule.