feat(api): scope-aware SQL totals for the History summary cards #675

Summary

Follow-up to #632. Summary cards and counts on the History view are computed from the capped, filtered slice, so they under-report once a cap is hit.

Current behaviour

summarizePurchaseHistory (internal/api/handler_history.go) sums over the rows already fetched (at most limit per source). With more rows than the cap the totals are wrong, and #630 only flags truncated.

Steps to verify the gap

More than 100 rows in range: card totals differ from a manual sum of all rows.

Expected behaviour

Totals and counts computed over ALL rows matching the filters, carrying the SAME scope predicate as the row fetch (otherwise they leak cross-tenant counts).

Proposed fix

• One combined store method HistorySummaryAggregate (COUNT by status, SUM upfront, SUM savings, revoked count) in internal/config/store_postgres.go with the same provider/account/date/scope predicates as fix(history): pending approvals can fall off the first page because filters are applied after the executions cap; add paging and push provider/account/date filters into the executions SQL #632 PR1/PR2.
• Preserve summarizePurchaseHistory semantics: revoked excluded from dollars, audit-gap excluded from dollars, canceled excluded, in-progress bucket.
• total/summary fields in HistoryResponse and internal/api/openapi.yaml.
• Cost: one COUNT/SUM scan per source; keep the default date window so an unfiltered view is bounded. No speculative index.
• Interface change touches the mock implementers: internal/mocks/stores.go, internal/analytics/collector_test.go, internal/server/test_helpers_test.go.

References

Parent #632, umbrella #248, #630. Severity: medium. Depends on #632 PR2 (scope predicate).