feat(ui): lightweight loading states for Dashboard & timeline so the UI isn't frozen during metrics load

[vybe]

Summary

While the Dashboard and timeline metrics are loading (see #1265 for the underlying latency), the UI renders nothing and looks completely frozen/dead — there is no signal that work is in progress. Add lightweight loading dynamics (skeleton placeholders / progressive rendering / subtle spinners) so that during the load the interface clearly communicates "loading" instead of appearing broken.

This is the perceived-performance half of the pair: #1265 makes the data arrive faster; this issue makes the wait feel responsive rather than dead.

Context

• On 10+ agent fleets the initial metrics load can take 20s+ (bug(perf): Dashboard & timeline take 20s+ to load metrics with 10+ agents — UI frozen until data arrives #1265). Even after that's optimized, any non-trivial load benefits from clear loading feedback.
• Keep it lightweight — skeletons/shimmers over the metric cards, charts, and timeline rows; no heavy spinner overlays that block the whole page.

Acceptance Criteria

• Dashboard metric cards/charts show skeleton placeholders (not blank/empty) while their data is loading.
• Timeline view shows skeleton rows or a progressive load indicator instead of an empty frozen area.
• Loading states appear immediately on navigation (don't wait for the slow request to resolve) and clear smoothly when data arrives.
• No layout shift / jank when skeletons are replaced by real content (reserve space).
• Dark-mode aware and consistent with existing component styling.
• Error/empty states are distinct from loading states (a failed load doesn't show an infinite skeleton).

Technical Notes

• Frontend-only; pairs with backend perf work in bug(perf): Dashboard & timeline take 20s+ to load metrics with 10+ agents — UI frozen until data arrives #1265.
• Reuse/extend existing chart components where possible (e.g. the Overview panel charts) so skeletons match real layout dimensions and avoid shift.
• Loading flags should live in the relevant Pinia stores (e.g. src/frontend/src/stores/executions.js) per the store=domain convention, with views rendering skeleton vs. content off those flags.
• Consider a small reusable skeleton component so Dashboard, timeline, and per-agent panels share one implementation.