fix(minimax,z-ai): stage api_key as root, restore mount mode 0400

Mirrors agent-runtimes commit 6f20b51. CRS serves these harness files to
dispatchers, so this repo must match.

Switches from "mount mode 0444 so the agent user can `cat` the ESO file"
to the gitea-ssh staging pattern: keep the ESO mount root-only (0400),
init.sh as root `install`s a per-secret 0600 agent-owned copy, and
apiKeyHelper points at the staged copy. Stronger blast-radius guarantee
— if the ESO Secret later grows additional keys, they remain root-only
unless the harness explicitly stages them.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

harnesses/contexts/minimax/v1/harness.yaml

@@ -18,12 +18,12 @@ secrets_required:
   - name: minimax
     account_ref: "minimax"
     mount_path: /run/agent/secrets/minimax
-    # 0444 — readable by the agent user that runs `claude` (and thus
-    # apiKeyHelper). The pod has no fsGroup, so the kubelet mounts the
-    # secret as root:root; mode 0400 would block the legitimate read.
-    # The file lives in pod-local tmpfs — "world readable" only means
-    # readable by other processes in this same pod, which we control.
-    mode: "0444"
+    # 0400 (root-only) — defense in depth. The agent user CANNOT read this
+    # mount. init.sh runs as root and `install`s a per-secret copy into the
+    # agent's home with mode 0600 owned by agent; only that copy is exposed
+    # to the runtime. Matches the gitea-ssh pattern. If the ESO Secret
+    # later grows additional keys, they remain inaccessible by default.
+    mode: "0400"
 
 scripts:
   init: ./init.sh