fix(api): canonicalise account_ids and forward multi-account selections everywhere #1452

Follow-ups from the #1448 reviews (#1429). None of them blocks #1448.

1. Uppercase account IDs fail without any error. parseAccountIDs (internal/api/validation.go) accepts uppercase UUIDs, but the IDs are compared case-sensitively afterwards. A scoped user is refused, which fails closed, and an admin silently gets an empty result. This affects both /history and the analytics routes. Fix: trim and lowercase in parseAccountIDs so every caller gets canonical IDs, the same way fix(history): apply the plan_id filter the plan-history view sends #1445 handles plan_id. Add a test with an uppercase ID on one history route and one analytics route.
2. Two views forward only a single account. frontend/src/modules/savings-history.ts (~125) and frontend/src/trends.ts (~85) still pass account_ids only when exactly one account is selected. With two or more selected, an admin sees every account and a scoped user gets a 400. The topbar account chip allows only one account today, so this can't happen yet, but it will once multi-select ships. Fix: forward the full selection through getSavingsAnalytics. trends.ts should send account_ids instead of the singular param.
3. Duplicate helper. mergeAccountFilter (internal/api/handler_analytics.go) duplicates the appendMissing / addExternalIDForProvider logic used by /history. Share one helper. Also fix the stale comment at handler_analytics.go ~154.