fix(health-check): give restarted services time to come up

[mattDev0]

The deploy for 83b61a4 worked — synced, re-execed cleanly, pulled images, recreated containers. It then failed its own post-deploy health check.

The race

22:05:50.18  Container devops-agent Started
22:05:50.87  Checking Agent (http://localhost:3011/livez)... FAILED   <- 0.7s later
22:06:03     Checking Orchestrator ... (retrying 1/15) ... OK         <- passed on attempt 4

The agent was probed 0.7 seconds after being started, with no retry.

Why it is systemic

check_endpoint defaults to max_attempts=1, and only the orchestrator was ever passed retry arguments:

check_endpoint "Agent"        ".../livez"          || FAILED=1   # 1 attempt
check_endpoint "Orchestrator" ".../health"  15 3   || FAILED=1   # 15 attempts
check_endpoint "Frontend"     ":8085"              || FAILED=1   # 1 attempt

The agent, orchestrator and frontend are all recreated on every deploy — so two of the three had no tolerance for startup time whatsoever. Prometheus, Grafana and node-exporter only passed because their images were unchanged, so compose left them running and never restarted them.

This would have been intermittent on the old server too. It surfaces reliably now because the new host is a single-vCPU B1s where startup is measurably slower.

Fix

Default raised to 10 attempts; the three recreated services get 15. The orchestrator keeps its existing 15 3 (Spring Boot is slowest to boot).

Verified against the running host — all six checks pass.

Note

Nothing was wrong with the deployment itself. The agent returned 200 on /livez moments later and every check passes now. The gate was the flaky part, not the deploy.

Also removes a stale comment claiming /health returns 503 without Kubernetes — since the graceful-degradation change it returns 200 with k8s: false.