fix: avoid spurious filter resets from concurrent loadDashboard calls

[jtroup]

what

In useDashboard.js, changed setFilters(updatedFilters) to a
functional update that preserves the existing state reference when
filter values are unchanged (using lodash.isEqual).

why

The failing e2e test Dashboard Filters > filters rows in a Table Visualization exposed a race condition introduced by the axios 0.30.x /
werkzeug 3.x upgrade (PR #88), which shifted request-completion timing.

On dashboard mount, two useEffect hooks independently call
loadDashboard(). Each call resolves its widget promises and calls
setFilters(collectDashboardFilters(...)). collectDashboardFilters
always returns a new array reference even when filter values are
identical. Each new reference triggers a useEffect in
VisualizationRenderer that calls combineFilters(localFilters, globalFilters), resetting any user-modified local filter selection back
to the global default.

With the new timing, this reset was firing after the test clicked a
filter option, causing the widget to display 4 rows instead of the
expected 3.

By preserving the existing reference when values are unchanged, spurious
effect triggers in VisualizationRenderer are suppressed, and local
filter selections survive concurrent loadDashboard() completions.

testing

Covered by the existing Cypress e2e test
client/cypress/integration/dashboard/filters_spec.js — specifically
Dashboard Filters > filters rows in a Table Visualization.

docs

No docs needed.

---

🤖 Generated with Claude Code

[ephan]

This looks good to me @jtroup