bug(api/dashboard): calculateCommitmentMetrics does not intersect allowed_accounts for scoped sessions

[cristim]

Summary

calculateCommitmentMetrics in handler_dashboard.go queries commitment data (reservations, savings plans) without filtering by the caller's allowed_accounts scope. A scoped session therefore sees commitment metrics aggregated across all accounts, not just the ones it has access to.

Reproduction

1. Create a session scoped to a subset of accounts via allowed_accounts.
2. Fetch the dashboard endpoint.
3. Observe that commitment totals include purchases from accounts outside the scope.

Expected behaviour

Commitment metrics should be restricted to the same account set that governs the rest of the dashboard (the set resolved by resolveDashboardAccountScope).

Notes

• resolveDashboardAccountScope already resolves accountUUIDs and accountExternalIDs from the session's allowed_accounts; calculateCommitmentMetrics needs to accept and apply both lists when querying.
• Deferred from PR fix(api): filter purchases by account UUID AND external id (closes #701, #498, #866) #956 (account-filter dual-column predicate) to keep that PR focused.

[cristim]

Verification sweep against main (101f099fb) on 2026-07-27 finds this already resolved.
calculateCommitmentMetrics now takes and applies the account scope.
Evidence: commit d086575 (#927).
Recommending close.

[cristim]

Verified resolved at 3c0f8ac: calculateCommitmentMetrics now takes the dashboard's resolved account UUIDs and per-provider external IDs and applies both when fetching active purchase history, so scoped sessions only aggregate commitments from their allowed accounts. Evidence: internal/api/handler_dashboard.go:69, :633-638 and :677 (#927). Residual axes checked: empty-scope fail-closed branch (:634), external-ID (non-UUID) account path forwarded alongside UUIDs; none found. Closing as completed; reopen if the behaviour recurs.