Add a startup probe so slow DSH cold starts are not killed (#6)

DSH takes tens of seconds to load plugins and start serving on a small
node, and every resume starts cold. The liveness budget (initialDelay
15s, period 15s, failureThreshold 3) is shorter than that, so the kubelet
killed the container mid-startup. DSH exits 0 on SIGTERM, which the
sandbox controller records as PodSucceeded/Finished - the pod is then
never recreated and the sandbox stays unusable until a manual
suspend/resume cycle.

Gate liveness and readiness behind a startupProbe on /favicon.svg with a
120s budget (24 x 5s, matching the gateway's WAKE_TIMEOUT). Liveness still
catches a genuinely hung server once startup succeeds.

Co-authored-by: SREDevOpsAgents <agents@sredevops.org>

examples/dsh-agents-as-a-service/10-sandboxtemplate.yaml

@@ -70,6 +70,19 @@ spec:
           # otherwise fail readiness and then get the pod killed by liveness.
           # /favicon.svg is served without auth and is the cheapest liveness
           # signal that proves the HTTP server is actually serving requests.
+          #
+          # Gate liveness/readiness behind a startup probe: a cold start on a
+          # small node takes tens of seconds to load plugins and start serving
+          # (a resumed sandbox starts cold too). Without it the kubelet can kill
+          # DSH mid-startup, and a SIGTERM'd DSH exits 0, which the sandbox
+          # controller records as finished. 24 x 5s = 120s, matching the
+          # gateway's WAKE_TIMEOUT.
+          startupProbe:
+            httpGet:
+              path: /favicon.svg
+              port: 3080
+            periodSeconds: 5
+            failureThreshold: 24
           readinessProbe:
             httpGet:
               path: /favicon.svg