feat(agent): Run deployment and service actions as streamed jobs

[nfebe]

Closes #150.

Start/stop/restart/rebuild for a whole deployment, and for a single service, were synchronous: compose output came back only on completion, so the UI could show nothing but a spinner and the result was lost on reload.

These actions now run as background jobs. The endpoint returns a job id immediately, compose output streams line by line over a websocket (authenticated with the same first-message handshake as the terminal endpoints), and the output is buffered so the job status stays queryable and survives a page reload. One action runs at a time per deployment, and per service within a deployment, so different services can act concurrently while the same target is rejected. Finished jobs are kept briefly in memory and are not retained across an agent restart, which the page-reload requirement does not need.

Service actions go through a single POST .../services/:service/job taking the action in the body, rather than a route per action.

Concurrency was checked under go test -race for the job and streaming paths; the e2e helpers now enqueue and poll to keep their existing synchronous behaviour.

[sourceant]

Code Review Summary

This PR converts synchronous deployment and service actions into asynchronous jobs. It introduces a job registry, WebSocket streaming for real-time logs, and state persistence for job results across page reloads.

🚀 Key Improvements

• Actions no longer block the HTTP request, preventing gateway timeouts.
• Real-time streaming of docker compose output via WebSockets.
• Concurrency control prevents multiple operations on the same service/deployment.
• Page reload survival for active and recently finished jobs.

💡 Minor Suggestions

• Add sc.Err() check in the streaming scanner.
• Consider refactoring the WebSocket auth handshake into a helper.

[sourceant]

Review complete. See the overview comment for a summary.

[sourceant]

When a subscriber channel is full, the line is dropped silently. While acceptable for 'live' updates, it might be safer to use a slightly larger buffer or a non-blocking check with a counter to log if users are consistently falling behind.

Suggested change

	for _, c := range j.subscribers {
	+ for _, c := range j.subscribers {
	+ select {
	+ case c <- line:
	+ default:
	+ }
	+ }

[sourceant]

Using a single scanner for both stdout and stderr with a shared mutex to update the combined buffer is correct, but there is a risk of a very long line (e.g., binary output or large build logs) causing the scanner to fail. The buffer increase to 1MB is good, but sc.Err() should be checked after the loop to detect if a line was skipped because it exceeded the buffer.

Suggested change

	scan := func(r io.Reader) {
	defer wg.Done()
	sc := bufio.NewScanner(r)
	// Image pull/build progress lines can be long; raise the per-line cap.
	sc.Buffer(make([]byte, 0, 64*1024), 1024*1024)
	for sc.Scan() {
	+ for sc.Scan() {
	+ line := sc.Text()
	+ sink(line)
	+ mu.Lock()
	+ combined.WriteString(line)
	+ combined.WriteByte('\n')
	+ mu.Unlock()
	+ }
	+ if err := sc.Err(); err != nil {
	+ sink("Error scanning output: " + err.Error())
	+ }