Home chart drifts from KPIs when a provider filter is active (analytics endpoint missing provider param)

[cristim]

Summary

The analytics endpoint that backs the Home page Savings-over-time chart accepts an account_ids filter but no provider param. PR #746 brought chart and KPI cards into account-filter parity, but when the user applies a provider filter (e.g. only AWS, only Azure), the KPIs above the chart correctly scope to the chosen provider while the chart aggregates across all providers — so the numbers drift visibly.

Repro

1. Open the Home page.
2. Apply a provider filter chip (e.g. "Azure").
3. Compare the "Potential Monthly Savings" KPI to the sum of the chart's last-N-days datapoints.
4. The KPI scopes to Azure; the chart still aggregates AWS + Azure + GCP.

Fix

Add a provider (or providers[] for multi-select) query param to the analytics handler. Mirror the same filter semantics as the KPI endpoint so the two sources of truth share the same scoping rules.

Suggested touchpoints (verify before editing):

• internal/api/handler_dashboard.go (or wherever getSavingsOverTime / the analytics route lives)
• frontend/src/dashboard.ts — pass provider alongside account_ids when fetching the chart series

Add a regression test asserting that with a provider filter active, the chart datapoint sums match the KPI value for the same range (within rounding epsilon).

Notes

PR #746 documented this as a known limitation in the dashboard.ts comments; this issue tracks the follow-up to actually close the gap.

[cristim]

Duplicate of #498 — fixed by PR #1122 (merged 2026-06-09).

Verified end-to-end on origin/main:

• internal/api/handler_analytics.go: getHistoryAnalytics reads params["provider"], validates via validateProvider, forwards to analyticsClient.QueryHistory.
• internal/api/analytics_postgres.go: QueryHistory appends provider = $N to the WHERE clause (see TestQueryHistory_ProviderFilter, TestQueryHistory_ProviderFilterWithAccount).
• frontend/src/dashboard.ts: loadSavingsTrendChart reads state.getCurrentProvider() and passes it to api.getSavingsAnalytics, matching the KPI fetch scope.

#764 was filed a couple of weeks before #498 was fixed; the two descriptions cover the same bug but the fix PR only linked to #498, so this one never auto-closed. Closing now.