ux(purchases): Savings History chart doesn't re-query on filter chip change and ignores account filter

[cristim]

Background

Discovered while fixing #498: the Purchases tab has its own
"Savings History" chart (#savings-history-chart, rendered by
frontend/src/modules/savings-history.ts) that has the same shape of
bug #498 fixed on the Home tab, plus an additional gap.

Two problems:

1. Subscriber wiring missing: initSavingsHistory() (line 306)
   only wires the period dropdown and refresh button. It does NOT
   subscribe to state.subscribeProvider / state.subscribeAccount,
   so changing the global Provider or Account chip does not refresh
   this chart. The Purchases tab must be left and re-entered for the
   filter to take effect.

2. Filter ignored in the request: loadSavingsHistory() (line 17)
   calls getSavingsAnalytics({ start, end, interval }) with NO
   provider or account_ids. The chart ALWAYS shows data for all
   accessible accounts, regardless of what the topbar chips show.

This is the Purchases-tab equivalent of #498 (Home tab) plus the
account-filter-passthrough gap.

Repro

1. Open the Purchases tab.
2. Open the Account chip in the topbar and select a specific account.
3. Observe the Savings History chart at the bottom of the page.

Expected: chart re-queries and shows only the selected account's
data.

Actual: chart shows the same data regardless of account selection,
and only refreshes when the user manually clicks Refresh or changes
the period dropdown.

What to do

Mirror the PR #498 fix pattern:

1. Add an isPurchasesTabActive() helper that checks
   #purchases-tab.active.
2. In initSavingsHistory(), subscribe to
   state.subscribeProvider / state.subscribeAccount with a
   coalesced scheduleReload (queueMicrotask + active-tab guard +
   reloadQueued flag), firing loadSavingsHistory().
3. Update loadSavingsHistory() to pass
   provider: state.getCurrentProvider() and
   account_ids: state.getCurrentAccountIDs() to
   getSavingsAnalytics.
4. (Depends on the backend follow-up): once the backend honours
   provider, the chart will be truly provider-filtered too. Until
   then, only account_ids actually filters.
5. Regression tests in
   __tests__/savings-history.test.ts (or wherever the suite for
   modules/savings-history.ts lives) covering:
   • chip change triggers loadSavingsHistory re-fetch,
   • inactive-tab guard,
   • request payload contains the current account_ids,
   • two consecutive account changes produce two fetches with distinct
     account_ids.

Acceptance criteria

• Changing the Account chip on the Purchases tab triggers an immediate
  re-fetch of /history/analytics.
• The fetch URL carries the selected account_id.
• The chart visibly redraws with the new account's data.
• No fetch fires when the user is on a non-Purchases tab.

[cristim]

Backend dependency unblocked: PR #716 (closes #701) is open and adds provider/account_ids/start/end filter support to the Purchase History handler. This was the missing backend piece for the Savings History chart re-query. The remaining work for this issue is now frontend-only: in frontend/src/modules/savings-history.ts initSavingsHistory(), subscribe to state.subscribeProvider and state.subscribeAccount (mirroring how recommendations.ts does it) and pass the current filter set when re-querying. The backend now honors those params, so the chart will actually refresh.

Dispatching a fix agent now.

[cristim]

Update: verified this is already implemented on the base branch feat/multicloud-web-frontend via PR #578 (merged 2026-05-22, commit 12aba9d8a).

frontend/src/modules/savings-history.ts initSavingsHistory() now registers state.subscribeProvider(scheduleReload) and state.subscribeAccount(scheduleReload) with queueMicrotask coalescing and an isPurchasesTabActive() guard. loadSavingsHistory() reads state.getCurrentProvider() / state.getCurrentAccountIDs() and passes them to getSavingsAnalytics(). 55/55 tests in savings-history.test.ts pass.

Backend support (provider / account_ids / start / end query params on the history handler) is in flight via #716. Once both #716 and feat/multicloud-web-frontend land on main, this issue is fully resolved end-to-end.

My prior comment dispatching a fix agent was redundant — the fix was already merged before that comment. Apologies for the noise.

[cristim]

Verification: shipped in PRs #578 (SHA 12aba9d) + #741 (SHA cb735f2), both merged and present on origin/feat/multicloud-web-frontend. savings-history.ts wires subscribeProvider/subscribeAccount to scheduleReload; loadSavingsHistory passes provider and account_ids to getSavingsAnalytics.