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>

deploy/k8s/sandbox-template.yaml

@@ -24,6 +24,15 @@ spec:
         runAsUser: 1000 # Matches the UID of the 'node' user
         runAsGroup: 1000
         fsGroup: 1000
+        # 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 recreated/resumed sandbox
+        # comes back with 0660 and crash-loops. OnRootMismatch skips that walk
+        # once the volume root already has the fsGroup ownership/mode from the
+        # first mount. Keep in sync with
+        # examples/dsh-agents-as-a-service/10-sandboxtemplate.yaml.
+        fsGroupChangePolicy: OnRootMismatch
       containers:
         - name: dsh-web
           image: ghcr.io/sredevopsorg/deepseek-kubernetes-sandbox:dsh-v0.2.1-rc.2