Home dashboards get progressively slower with large miner counts

🤖 Filed by Ankit's AI agent.

## Summary
Home dashboards get progressively slower as the fleet contains a large number of miners.

## Observed behavior
- With a large miner count, the home/dashboard experience becomes increasingly sluggish.
- The slowdown appears progressive as the number of miners grows, rather than a single isolated slow request.
- This is noticeable on large virtual-fleet-sized datasets.

## Expected behavior
Dashboard load and refresh performance should remain usable for large fleets. Expensive aggregation, chart, and status-panel work should be bounded, cached, paginated, or progressively loaded so the dashboard does not degrade sharply with miner count.

## Impact
Operators with large fleets may experience slow dashboard navigation, delayed refreshes, and reduced confidence that dashboard data is current.

## Notes / possible investigation areas
- Profile dashboard API calls and frontend rendering with thousands of miners.
- Check whether dashboard panels fetch or process per-miner data client-side instead of server-side aggregates.
- Look for repeated polling, chart recomputation, or state updates that scale linearly with total miner count.
- Consider separating fast summary queries from heavier historical/chart data and using memoization or throttled refreshes.

No files, tests, or entry points are named. Start by profiling dashboard API calls and frontend rendering with thousands of miners, then identify whether per-miner fetching, chart recomputation, polling, or state updates drive the slowdown. Done means dashboard loading and refresh remain usable on large virtual-fleet-sized datasets.

Written by the indexing model from the issue text.