chore(security): add guardrails against secret values in error strings (#5244)

* fix(kms): do not include secret value in static KMS format error

The malformed-format error message in build_static_kms_config embedded the
raw env var value. The most likely misconfiguration is setting
RUSTFS_KMS_STATIC_SECRET_KEY to the bare base64 key without the <key-name>:
prefix, in which case the full secret key material would be written to
startup logs. Drop the value from the message, matching the equivalent
parsing error in KmsConfig::from_env().

* chore(security): add guardrails against secret values in error strings

Follow-up to the PR #5222 review finding fixed in PR #5243: a config value
that fails secret-format parsing is typically the raw secret itself, and
error messages are log content — they propagate via ? and are printed by
startup/error logging far from the construction site.

Three layers so this class of leak is caught earlier next time:

- security-advisory-lessons: state explicitly that error/panic messages are
  log content; parse-failure hints must name the env var and expected
  format, never echo the input. Add a matching review prompt.
- adversarial-validation: add a security-reviewer probe that greps
  error-construction sites on secret-bearing config paths for interpolation
  of the raw value, including the duplicated-parse trap where the leak hid.
- check_logging_guardrails.sh: mechanical backstop — flag inline format
  interpolation of secret-named identifiers (secret/password/passwd/
  private_key) in checked files; add crates/kms/src/config.rs (the twin
  parse site) to the checked list. Verified the check passes on the fixed
  tree and catches the original leak at rustfs/src/init.rs:399.

scripts/check_logging_guardrails.sh

@@ -26,6 +26,7 @@ checked_files=(
   "rustfs/src/admin/handlers/system.rs"
   "rustfs/src/storage/rpc/http_service.rs"
   "rustfs/src/storage/rpc/node_service.rs"
+  "crates/kms/src/config.rs"
   "crates/audit/src/pipeline.rs"
   "crates/audit/src/system.rs"
   "crates/audit/src/global.rs"
@@ -655,6 +656,23 @@ for pattern in "${forbidden_patterns[@]}"; do
   fi
 done
 
+# Secret material must never be interpolated into log or error strings.
+# Error messages are log content: they propagate via `?` and are printed by
+# startup/error logging far from the construction site, and a value that fails
+# secret-format parsing is typically the raw secret itself (PR #5222/#5243:
+# `got: {secret_str}` would have echoed a bare base64 KMS key into startup
+# logs). Parse-failure hints must name the env var and expected format only.
+# Heuristic: flag inline format interpolation of secret-named identifiers.
+# Uppercase const names (env-var names like ENV_KMS_STATIC_SECRET_KEY) do not
+# match by design; test assertion messages only print on local test failure.
+secret_interpolation='\{[a-z_]*(secret|password|passwd|private_key)[a-z_]*(:[^}]*)?\}'
+secret_hits="$(rg -n -- "$secret_interpolation" "${checked_files[@]}" | rg -v 'assert' || true)"
+if [[ -n "$secret_hits" ]]; then
+  echo "❌ logging guardrail violation: secret-named variable interpolated into a format/log/error string" >&2
+  echo "$secret_hits" >&2
+  exit 1
+fi
+
 systemd_unit="deploy/build/rustfs.service"
 if rg -n '^Standard(Output|Error)=append:.*rustfs.*\.log$' "$systemd_unit" >/dev/null; then
   echo "❌ logging guardrail violation: systemd must not append stdout/stderr to a RustFS-managed rolling log" >&2