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

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.