ux(home): Account filter doesn't affect Home page Savings-over-time graph (data identical across accounts)

[cristim]

Repro

On the Home page (the top-level dashboard, not Opportunities):

1. Open the Account filter dropdown in the top-bar.
2. Switch the selected Account one at a time, going through every available account.
3. Observe the Savings over time chart (and any other graphs) at the top of the page.

Expected

KPIs and graphs re-query and re-render so they show data for only the selected account.

Actual

"The potential Savings graph shows the same data for each account. Can't confirm if data itself is correct."

The Home page graph renders identical data for every account selection — the account filter does not appear to affect the data flowing into the graph at all. (Provider filter is similarly unreliable per row 2.2 — see Notes.)

Why this matters

The data on the Home page is the first thing users see. If the Account filter silently no-ops, users can be looking at a graph they believe represents one account while it actually aggregates across all accounts — that's misleading data on the most-visible surface.

Relationship to #477

#477 fixed an analogous bug on the Opportunities page (provider/account filter changes didn't re-render the list). PR #488 wired up state subscribers + URL persistence there. The Home page likely needs the equivalent wiring on its own chart/KPI render path — the chart subscriber should fire load(...) for the selected provider+account on every chip change, not just on initial route enter.

Suggested fix path:

1. Find the Home page chart's data load function (likely a loadHomeSavingsChart() or similar).
2. Subscribe to state.subscribeProvider and state.subscribeAccount from the chart module's init.
3. Each callback fires the chart's data load only when the Home tab is active.
4. Persist filter state to URL params (matches PR fix(ux/opportunities): re-query on filter change and persist to URL #488's pattern, gives shareable links).
5. Add regression tests that fire a chip change and assert the chart re-queries.

QA reference

Home page sheet, row 8 (step 2.3).

Provider-filter caveat (row 2.2)

Row 2.2 (Provider filter) reports "graph adjusts. Can't confirm if data itself is correct." — the symptom there is less clearly broken (the graph at least changes shape), but a re-test once the account filter is fixed would tell us whether the provider path is sound.

[cristim]

Verification: shipped in PR #747 (SHA 3931e9e, merged 2026-05-27). dashboard.ts wires subscribeAccount/subscribeProvider to scheduleDashboardReload; loadSavingsTrendChart passes account_ids and provider to the analytics call. Confirmed present on origin/feat/multicloud-web-frontend.