Separate temporal summary queries from paginated history lists

A fast paginated history list does not establish that its dashboard summaries are cheap. When each displayed row needs history as of its own creation time, batched PostgreSQL SQL can repeat identity reconstruction and evidence aggregation for many requested timestamps. Measure that summary operation separately and keep optional history enrichment off the synchronous page-render path. Any query optimization or deferred loading must preserve the original authorization scope and each row's historical cutoff; replacing the summary with current all-time totals changes its meaning.

Applies when: A customer-specific dashboard waits for temporal history summaries even though its standalone history list is responsive. Keywords: PostgreSQL dashboard latency temporal history summaries batching identity reconstruction server rendering