perf(desktop): Usage activity log is slow with large histories #4531

What happened

Opening or returning to Settings → Usage → Activity log becomes noticeably slow when the usage history contains hundreds of detailed records.

The usage data is already cached. The delay comes from mounting the entire activity table every time the tab is shown. With 409 records, the renderer creates all 409 rows, including their cells, truncation measurements, tooltips, and session buttons, even though only a small portion is visible.

The Activity log should remain responsive with a large history and should not render every record at once.

How to reproduce

1. Run Maka Desktop with detailed usage tracking enabled.
2. Accumulate several hundred Activity log records (409 records reproduced the issue).
3. Open Settings → Usage.
4. Switch away from Activity log, then switch back to it.
5. Observe that the tab takes a noticeable amount of time to become responsive on every switch.

Environment

• Maka commit: 6c632b133
• OS: macOS 26.6.2 (25G83)
• Surface: Desktop
• Node.js: 24.16.0

Logs, screenshots, or additional context

The proposed pagination renders 50 records per page. For the 409-record reproduction, this reduces the number of table rows mounted per visit from 409 to 50, an 87.8% reduction.

For an A/B benchmark, use the same 409-record fixture and machine, switch into Activity log at least 10 times on both revisions, and compare the median and p95 render-completion time. The final timing results can be added to the corresponding pull request.