Credentials exposed as env vars instead of mounted read-only volumes

Summary
The operator injects sensitive credentials as plaintext environment variables into pod containers instead of mounting them as read-only volumes:

• PGPASSWORD_SUPERUSER, PGPASSWORD_STANDBY
• AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY

Per OWASP's Kubernetes Security Cheat Sheet: "It is best for secrets to be mounted into read-only volumes in your containers, rather than exposing them as environment variables." Env vars are readable via /proc//environ, process listings, and are prone to leaking into logs/crash dumps.

Expected Behavior

• AWS credentials for WAL-E/WAL-G should be mounted as a read-only credentials file (e.g. ~/.aws/credentials) instead of AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY env vars. This requires corresponding support in spilo's entry_point.sh, which currently reads these values from the environment.
• Postgres superuser/standby/monitoring passwords should be mounted as a read-only .pgpass file (or equivalent Patroni file-based credential support) instead of PGPASSWORD_SUPERUSER/PGPASSWORD_STANDBY/POSTGRES_PASSWORD env vars.

Impact

Compromise of any of these containers, or any way to read /proc//environ, exposes long-lived AWS IAM keys (full access to the WAL backup bucket — exfiltrate, delete, or tamper with backups) and/or the Postgres superuser password (full database access).

Reference

OWASP Kubernetes Security Cheat Sheet — "Keep secrets as secrets": https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html#keep-secrets-as-secrets

Trace where the operator injects PGPASSWORD and AWS credential environment variables, then read spilo's entry_point.sh, which currently consumes the AWS values from the environment. Check the stated WAL-E/WAL-G credential-file and Patroni file-based credential requirements. Done means the listed credentials are supplied through read-only mounted files rather than environment variables, with the dependent components still able to use them.