feat(filters): consistent provider+account dropdown filtering across all main tabs

[cristim]

Background

The provider/account dropdown pair is the primary lens our users have onto the data. Today the coverage is uneven across the five main tabs:

Tab	Provider dropdown	Account dropdown	Refresh-on-change
Dashboard	✓	✓	⚠ flaky — see #185
Recommendations	✗	per-column filter only (multi-select popover)	column-filter re-renders client-side, no API re-fetch
Purchase Plans	✓	✓	✓ both wired
Purchase History	✓	✓	⚠ provider re-populates account list, but neither dropdown's change event triggers loadHistory() — user must hit the date-range Apply button to actually re-query
RI Exchange	✗	✗	n/a

This means the same operator action ("scope my view to AWS account 1234") behaves differently on every tab, and on Recommendations + RI Exchange isn't even possible without per-column popovers or backend filters.

Acceptance criteria

For every main tab — Dashboard, Recommendations, Purchase Plans, Purchase History, RI Exchange:

1. A consistent Provider + Account dropdown pair is rendered at the top of the tab (or in a tab-local toolbar).
2. The Account dropdown is populated from the same populateAccountFilter helper used today, scoped to the current provider value.
3. Changing the Provider dropdown:
   • Repopulates the Account dropdown (filtered to that provider's accounts).
   • Resets the Account selection to "(All accounts)".
   • Calls the tab's load*() to re-fetch data.
4. Changing the Account dropdown:
   • Sets state.currentAccountIDs to [id] or [] for "All accounts".
   • Calls the tab's load*() to re-fetch data.
5. Both dropdowns survive populateAccountFilter repopulation without losing their change listeners.
6. Each tab's load path passes currentProvider + currentAccountIDs to its API call (most already do).
7. Tests pin the change-→-load round-trip per tab.

Existing pattern to follow

frontend/src/plans.ts:1080-1100 already gets this right (provider + account filters, both wired to loadPlans). Use it as the template; lift the wiring helper into frontend/src/utils.ts if the duplication starts to bite.

Backend considerations

• Recommendations: api.getRecommendations(provider, accountIDs) already accepts account IDs (used today by the per-column popover). Top-level dropdown is purely a UI add.
• RI Exchange: api.getRIExchange* calls today don't take an account filter. Likely a small backend change to add ?account_id=… query parameter on the relevant endpoints. Verify before estimating effort.
• History: dropdowns exist; just need the change → loadHistory() wiring (one-line per dropdown).

Suggested split

This is naturally a 5-PR feature, one per tab. Suggest landing in this order so the highest-impact tab ships first:

1. Recommendations — primary user surface, currently has no top-level account filter.
2. RI Exchange — currently has no filter at all.
3. History — wire the existing dropdowns to refresh on change (smallest diff).
4. Dashboard — fix the refresh-on-change bug (already tracked separately as fix(dashboard): account dropdown change doesn't reliably refresh dashboard data #185).
5. Plans — verify already-correct behaviour and add a regression test.

References

• frontend/src/dashboard.ts:26-50
• frontend/src/plans.ts:1080-1100
• frontend/src/history.ts:69-77
• frontend/src/recommendations.ts (per-column popover machinery, applyColumnFilters)
• frontend/src/riexchange.ts:50-58
• frontend/src/utils.ts:populateAccountFilter

[cristim]

Verification

Original concern: Provider+Account dropdown coverage is uneven across the five main tabs. Acceptance criteria: a consistent provider+account dropdown pair on every main tab (Dashboard, Recommendations, Purchase Plans, Purchase History, RI Exchange), Provider change → repopulates Account → resets selection → re-fetches; both dropdowns survive populateAccountFilter repopulation; tests pin the round-trip per tab.

What merged: PR #190 (fix(dashboard): clear stale account state on provider switch) is the only merged PR linked here. It addresses sibling issue #185 (Dashboard refresh race) and is a prerequisite for #186, but is scoped to the Dashboard tab only.

Code state today (origin/feat/multicloud-web-frontend):

• Dashboard, Plans, History — top-level <select id="*-provider-filter"> + <select id="*-account-filter"> exist in frontend/src/index.html (lines 47-57, 109-119, 191-199).
• Recommendations — top filter bar was deliberately removed in Bundle B (frontend/src/recommendations.ts:53-61). The handler is now a no-op, with column-popover filtering replacing the dropdowns. No new top-level dropdown was reinstated.
• RI Exchange — no provider-filter / account-filter controls in index.html or riexchange.ts. Grep returns nothing.
• History change → loadHistory wiring (the issue's small History fix bullet) — not verified beyond the dropdown's existence; needs separate confirmation if you keep this open.

So the unification across all five tabs is not complete. Dashboard (now correct) and Plans (already correct) are fine. Recommendations + RI Exchange still have no top-level provider/account dropdowns; History's change wiring is separately untracked.

Recommendation: keep-open. Missing: top-level provider+account dropdowns on Recommendations + RI Exchange, plus their backend wiring (api.getRIExchange* may need an account_id query parameter as the issue flagged), plus History's change → loadHistory() wiring. Filing a smaller follow-up per remaining tab as the issue's "5-PR feature" plan suggested would also work.

[cristim]

Verified shipped: merge commit d986b4d (PR #582) is in origin/feat/multicloud-web-frontend (compare API: feat is ahead of d986b4d). PR #582 body says "Closes #186" and wires provider/account subscriptions to the RI Exchange tab. PR #190 (merge commit cedcade, also in feat) contributed the dashboard slice of the same umbrella feature.