feat(observ): Add observability UI, plugin slots, notifications settings

[nfebe]

The UI half of observability and self-recovery (#148). Pairs with flatrun/agent#165.

A fleet overview under a new Monitoring group in the sidebar, with time-series graph panels for CPU, memory, and network instead of the flat stat lists the earlier version showed, plus a recovery timeline and a "needs attention" list. Managed deployments deep-link to their metrics tab; external containers are listed but not linked, since there is nothing for FlatRun to act on.

A slot system lets any plugin inject UI: a deployment's detail view renders plugin-contributed tabs, and settings renders plugin-contributed config forms from each plugin's schema. Observability is the first consumer; the mechanism is generic.

Notifications become a core settings tab. Instead of hand-writing shoutrrr URLs, targets are configured through per-service fields (email or webhook) that build the URL, with a test-send per target.

Also fixes a client-side ID crash: crypto.randomUUID only exists in a secure context, so adding a database connection or notification target failed with "not a function" over plain HTTP on a LAN address. IDs now fall back to a getRandomValues UUID.

[sourceant]

Code Review Summary

This PR introduces a robust observability suite and a generic plugin UI slot system. It significantly improves the monitoring capabilities of FlatRun and solves a critical bug regarding UUID generation in non-HTTPS environments.

🚀 Key Improvements

• Introduction of PluginSlot.vue for modular UI extension.
• Real-time monitoring charts using uplot for efficiency.
• Standardized notification target configuration with structured fields.
• Resilient UUID generation fallback for LAN/plain HTTP usage.

💡 Minor Suggestions

• Optimize chart re-rendering in TimeSeriesChart.vue to use setData instead of full destruction.
• Add a watcher for active tabs in DeploymentDetailView.vue to handle dynamic plugin state changes.

[sourceant]

Review complete. See the overview comment for a summary.

[sourceant]

While the logic is correct, the string formatting can be simplified using Intl.NumberFormat or a cleaner slice pattern for better maintainability. Additionally, ensuring the high-order bits of the first byte of the variant (byte 8) are correct is crucial for RFC 4122 compliance, which you have handled.

Suggested change

	const hex = Array.from(bytes, (b) => b.toString(16).padStart(2, "0"));
	const hex = Array.from(bytes, (b) => b.toString(16).padStart(2, "0")).join("");
	return `${hex.slice(0, 8)}-${hex.slice(8, 12)}-${hex.slice(12, 16)}-${hex.slice(16, 20)}-${hex.slice(20, 32)}`;

[sourceant]

Security risk: Credentials (username/password) are being URI-encoded but still transmitted as part of a URL string. Ensure that when these are saved to the backend, the backend treats these URLs as sensitive/encrypted at rest. Also, the password should be cleared from the local reactive state after adding to the target list to minimize memory exposure.

Suggested change

	const cred = e.username ? `${encodeURIComponent(e.username)}:${encodeURIComponent(e.password)}@` : "";
	const cred = e.username ? `${encodeURIComponent(e.username)}:${encodeURIComponent(e.password)}@` : "";
	const params = new URLSearchParams({ fromAddress: e.from, toAddresses: e.to, useStartTLS: "yes" });
	const url = `smtp://${cred}${e.host}:${e.port || "587"}/?${params.toString()}`;
	return url;

[sourceant]

Performance: chart.destroy() followed by new uPlot() on every container/data change is heavy. uPlot is designed to handle data updates via setData and series updates via addSeries/delSeries. Complete re-renders should be avoided unless the series count changes significantly.

Suggested change

	if (chart) {
	if (chart) {
	if (props.containers.length === chart.series.length - 1) {
	chart.setData(data());
	return;
	}
	chart.destroy();
	}