fix: subshell-scope umask 077 in so_pillar key generation

The unscoped `umask 077` on postsalt's secrets_pillar path leaked into
every subsequent file write by so-setup (and the salt-call processes
it spawned) for the rest of the install. Every state-rendered config
file under /opt/so/conf landed at mode 0600 instead of 0644, which
broke any container that bind-mounts its config read-only and runs as
a non-root user after the entrypoint's gosu drop. The first concrete
casualty was the influxdb container, which exits with
  "failed to load config file: open /conf/config.yaml: permission denied"
after init mode completes and re-execs as the influxdb user.

The chmod 0400 immediately after the printf already enforces the
intended file mode, so the umask was redundant for the key file
itself; scoping it to a subshell preserves the defense-in-depth
between the printf and the chmod without polluting the parent shell.

setup/so-functions

@@ -1900,8 +1900,17 @@ secrets_pillar(){
 	if [ -z "$SO_PILLAR_KEY" ]; then
 	  SO_PILLAR_KEY=$(get_random_value 64)
 	fi
-	umask 077
-	printf '%s' "$SO_PILLAR_KEY" > /opt/so/conf/postgres/so_pillar.key
+	# Subshell-scope the umask so it doesn't leak into subsequent so-setup
+	# (and salt-call) file writes. Without the (...) wrapper the umask 077
+	# persists for the rest of the install and every state-rendered config
+	# file under /opt/so/conf lands at 0600 — which breaks containers that
+	# bind-mount their config and run as a non-root user (the influxdb
+	# container, in particular, exits with "permission denied" on
+	# /conf/config.yaml after the gosu drop).
+	(
+	  umask 077
+	  printf '%s' "$SO_PILLAR_KEY" > /opt/so/conf/postgres/so_pillar.key
+	)
 	chmod 0400 /opt/so/conf/postgres/so_pillar.key
 	chown root:root /opt/so/conf/postgres/so_pillar.key
   fi