feat(ui): Build the dashboard view over container and serving metrics

[nfebe]

The dashboard endpoints and a typed client shipped with the observability work (flatrun/agent#174, ui #82) but nothing consumed them, so stored dashboards were unreachable. This adds the view they were staged for, reusing that backend, the dashboardsApi client, and the existing chart component rather than adding new plumbing.

Dashboards can be created, renamed, and deleted. Each holds panels on a twelve-column grid; a panel plots a container metric (CPU, memory, network) or a serving metric (requests, errors, latency), for one deployment or all, as a line chart or a single stat, over a selectable range. Panel data comes from the metric endpoints the observability screens already use, so nothing new is collected.

Unverified: the render against a live agent with real metrics. Covered by component tests over the data adaptation and the create flow, plus type-check and build, but not driven end to end against a running backend.

[sourceant]

Code Review Summary

This PR successfully implements a functional Dashboard view, allowing users to customize and view container and serving metrics in a grid layout. It reuses existing API clients and charting components effectively.

🚀 Key Improvements

• Integrated dashboard persistence with the backend dashboardsApi.
• Implemented a flexible 12-column grid system for panels.
• Added support for both container-level and proxy-level (serving) metrics.
• Included comprehensive unit tests for data adaptation and UI interactions.

💡 Minor Suggestions

• Consider standardizing unit suffix casing in formatStat (e.g., 'KB' vs 'k').
• Replacing bitwise shifts with safe numerical constants for large byte values to avoid 32-bit integer overflow issues.

[sourceant]

Review complete. See the overview comment for a summary.

[sourceant]

Using bitwise operators like 1 << 30 in JavaScript is limited to 32-bit signed integers. While this works for values up to ~2GB, memory metrics for large containers or node-level aggregates can exceed this range. It's safer to use numerical literals. Additionally, adding 'B' to the unit suffixes (e.g., 'GB' instead of 'G') would make the units more explicit and consistent with the base 'B' case.

Suggested change

	if (u === "bytes") {
	if (u === "bytes") {
	if (v >= 1073741824) return `${(v / 1073741824).toFixed(1)}GB`;
	if (v >= 1048576) return `${(v / 1048576).toFixed(0)}MB`;
	if (v >= 1024) return `${(v / 1024).toFixed(0)}KB`;
	return `${v}B`;
	}