Fix DSH crash-loop after suspend/resume (fsGroup chmod) (#5)

Resuming a sandbox recreates its pod on the same PVC. The kubelet's default
fsGroup policy ("Always") recursively ORs 0660 into every file on each pod
start, so DSH's .credentials.yaml — created 0600 — comes back as 0660. The
credentials plugin refuses to boot in that case:

  credentials-local: .../.credentials.yaml is readable beyond its owner
  (mode 660); run "chmod 600 ..."

That makes the first resume after a suspend crash-loop, which breaks the
example's step 6 and any gateway wake-on-connect.

Set fsGroupChangePolicy: OnRootMismatch on both sandbox templates. The
kubelet then skips the recursive walk when the volume root already carries
the fsGroup ownership/mode applied on the first mount — exactly the
suspend/resume case, while a fresh PVC is still chowned correctly.

Document the upgrade path: Sandbox objects snapshot their pod template, so
existing sandboxes and warm-pool members need the policy patched (plus a
one-time chmod 600) or must be recreated.

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

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

@@ -34,6 +34,15 @@ spec:
         runAsGroup: 1000
         fsGroup: 1000
         runAsNonRoot: true
+        # DSH's credentials plugin refuses to start when .credentials.yaml has
+        # any group/other permission bit (it creates the file 0600). The
+        # default kubelet fsGroup policy ("Always") recursively ORs 0660 into
+        # every file each time the pod starts, so a resumed sandbox comes back
+        # with 0660 and crash-loops before the gateway can proxy to it.
+        # OnRootMismatch skips that walk once the volume root already carries
+        # the fsGroup ownership/mode applied on the first mount.
+        # Keep in sync with deploy/k8s/sandbox-template.yaml.
+        fsGroupChangePolicy: OnRootMismatch
       containers:
         - name: dsh-web
           image: ghcr.io/sredevopsorg/deepseek-kubernetes-sandbox:dsh-v0.2.1-rc.2