feat(dashboard): per-card loading with field-level usages API

[GenerQAQ]

Why we need this PR?

Replace the monolithic dashboard loading experience (global backdrop-blur overlay blocking entire page) with progressive per-card loading, so users see chart data as it arrives.

Describe your solution

• Frontend API client: getDashboardData now accepts optional fields param, appending &fields=a,b to the usages endpoint
• Server actions: Added validateDashboardAccess() for auth check, fetchDashboardGroup() for field-scoped fetches across 5 groups (tasks, session_metrics, task_metrics, storage, counts)
• DashboardCharts: Refactored from single dashboardData + isLoading to per-group data + loadingGroups. Each ChartCard now has its own blur overlay with spinner
• ProjectPageClient: Fires 5 parallel group fetches on mount, each updates its own state independently via .then(). Removed global loading overlay (kept only "no API key" dialog)
• loading.tsx: Simplified to header + time range skeleton only

Note: Backend changes (fields query param on /usages endpoint) are in the Acontext-admin repo and need a separate PR there. Frontend is fully backwards compatible — when backend doesn't support fields, the full response is returned as before.

Implementation Tasks

• Add fields param to getDashboardData in admin.ts
• Add validateDashboardAccess, fetchDashboardGroup server actions
• Add isLoading prop to ChartCard with per-card blur + spinner overlay
• Refactor DashboardCharts to accept per-group data and loading state
• Rewrite ProjectPageClient orchestration with 5 independent group fetches
• Simplify loading.tsx (per-card blur handles chart loading)
• Remove unused project-page-skeleton.tsx

Impact Areas

• Dashboard

Checklist

• Open your pull request against the dev branch.
• All tests pass in available continuous integration systems (e.g., GitHub Actions).
• Tests are added or modified as needed to cover code changes.

🤖 Generated with Claude Code