[NX-204 Issue] Add secret management guidelines and enhance security notes

Introduced a comprehensive guide for secure production secret handling (`docs/security/secret-management.md`). Updated `.env.example` files with clearer comments on best practices, emphasizing not hardcoding secrets and implementing rotation strategies. Enhanced README with a new section linking to the secret management documentation.

docs/security/secret-management.md

@@ -0,0 +1,74 @@
+# Secret Management (Production)
+
+This guide defines secure handling for NexaPG secrets in production deployments.
+
+## In Scope Secrets
+
+- `JWT_SECRET_KEY`
+- `ENCRYPTION_KEY`
+- `DB_PASSWORD`
+- SMTP credentials (configured in Admin Settings, encrypted at rest)
+
+## Do / Don't
+
+## Do
+
+- Use an external secret source (Vault, cloud secret manager, orchestrator secrets, or CI/CD secret injection).
+- Keep secrets out of Git history and out of image layers.
+- Use strong random values:
+  - JWT secret: at least 32+ bytes random
+  - Fernet key: generated via `Fernet.generate_key()`
+- Restrict access to runtime secrets (least privilege).
+- Rotate secrets on schedule and on incident.
+- Store production `.env` with strict permissions if file-based injection is used:
+  - owner-only read/write (e.g., `chmod 600 .env`)
+- Audit who can read/update secrets in your deployment platform.
+
+## Don't
+
+- Do **not** hardcode secrets in source code.
+- Do **not** commit `.env` with real values.
+- Do **not** bake production secrets into Dockerfiles or image build args.
+- Do **not** share secrets in tickets, chat logs, or CI console output.
+- Do **not** reuse the same secrets between environments.
+
+## Recommended Secret Providers
+
+Pick one of these models:
+
+1. Platform/Cloud secrets
+   - AWS Secrets Manager
+   - Azure Key Vault
+   - Google Secret Manager
+2. HashiCorp Vault
+3. CI/CD secret injection
+   - Inject as runtime env vars during deployment
+4. Docker/Kubernetes secrets
+   - Prefer secret mounts or orchestrator-native secret stores
+
+If you use plain `.env` files, treat them as sensitive artifacts and protect at OS and backup level.
+
+## Rotation Basics
+
+Minimum baseline:
+
+1. `JWT_SECRET_KEY`
+   - Rotate on schedule (e.g., quarterly) and immediately after compromise.
+   - Expect existing sessions/tokens to become invalid after rotation.
+2. `ENCRYPTION_KEY`
+   - Rotate with planned maintenance.
+   - Re-encrypt stored encrypted values (target passwords, SMTP password) during key transition.
+3. `DB_PASSWORD`
+   - Rotate service account credentials regularly.
+   - Apply password changes in DB and deployment config atomically.
+4. SMTP credentials
+   - Use dedicated sender account/app password.
+   - Rotate regularly and after provider-side security alerts.
+
+## Operational Checklist
+
+- [ ] No production secret in repository files.
+- [ ] No production secret in container image metadata or build args.
+- [ ] Runtime secret source documented for your environment.
+- [ ] Secret rotation owner and schedule defined.
+- [ ] Incident runbook includes emergency rotation steps.