refactor(agent): Gather dashboard and deployment data concurrently

[nfebe]

The agent assembled the dashboard stats and the deployment list by running every docker and OS call in sequence. Each deployment's status check shells out to docker compose, so a host with many deployments paid that cost once per deployment, and the dashboard endpoint stacked another dozen independent docker/OS calls on top, all serial. Both add up to noticeably slow dashboard loads, which is the substance of #154.

The independent calls now run concurrently. Deployment status checks and network inspections use a bounded worker pool (12); the dashboard endpoint fans its independent lookups out and waits for all of them. Output is identical: each worker writes only its own slot, and results stay in their original order. Load time drops from the sum of the calls toward the slowest single call.

One thing a reviewer should weigh: a single dashboard request can now spawn up to roughly 35 concurrent docker processes at peak (the endpoint's own fan-out plus the nested pools inside the deployment and network lookups). On a small host that's a transient spike. If it shows up under load, a shared cap across the docker-calling managers is the follow-up; the per-site bound of 12 is the floor for now.

[sourceant]

Code Review Summary

The PR refactors the agent to gather dashboard and deployment data concurrently rather than sequentially. This addresses issue #154 where dashboard loading was slow due to accumulated latencies from multiple Docker/OS shell commands.

🚀 Key Improvements

• Parallelized the gathering of system stats, container stats, image stats, etc., in the API layer.
• Introduced a bounded worker pool (limit 12) for deployment status checks in internal/docker/manager.go.
• Introduced a bounded worker pool (limit 12) for network inspections in internal/networks/manager.go.

💡 Minor Suggestions

• Explicitly localizing variables within goroutine closures to avoid any future data race risks when aggregating counts.

[sourceant]

Review complete. See the overview comment for a summary.

[sourceant]

The variable portCount is being modified inside a goroutine without synchronization (e.g., atomic or mutex). While each closure is intended to write to its own variable, this loop iterates over containers and increments a shared portCount across the outer scope. If the slice were processed concurrently, this would be a data race. In the current specific structure, only one goroutine touches portCount, so it is technically safe, but it is fragile if other concurrent tasks are added or if this block is refactored.

Suggested change

	run(func() {
	run(func() {
	if containers, err := s.networksManager.ListContainers(); err == nil {
	localPortCount := 0
	for _, container := range containers {
	localPortCount += len(container.Ports)
	}
	portCount = localPortCount
	}
	})