Clarify how the existingSecret really works

charts/trek/templates/NOTES.txt

@@ -2,8 +2,11 @@
    - ENCRYPTION_KEY encrypts stored secrets (API keys, MFA, SMTP, OIDC) at rest.
    - By default, the chart creates a Kubernetes Secret from `secretEnv.ENCRYPTION_KEY` in values.yaml.
    - To generate a random key at install (preserved across upgrades), set `generateEncryptionKey: true`.
-   - To use an existing Kubernetes secret, set `existingSecret` to the secret name. The secret must
-     contain a key matching `existingSecretKey` (defaults to `ENCRYPTION_KEY`).
+   - To use an existing Kubernetes secret, set `existingSecret` to the secret name. The chart then
+     renders no Secret of its own and reads every secret env var from that secret: `ENCRYPTION_KEY`
+     (renamable via `existingSecretKey`), plus `ADMIN_EMAIL`, `ADMIN_PASSWORD`, `OIDC_CLIENT_SECRET`,
+     `UNSPLASH_ACCESS_KEY`, `AMAP_API_KEY` and `AMAP_API_SECRET`. Missing keys are simply left unset,
+     so only provide the ones you use.
    - If left empty, the server resolves the key automatically: existing installs fall back to
      data/.jwt_secret (encrypted data stays readable with no manual action); fresh installs
      auto-generate a key persisted to the data PVC.

charts/trek/values.yaml

@@ -171,7 +171,11 @@ secretEnv:
 # If true, a random ENCRYPTION_KEY is generated at install and preserved across upgrades
 generateEncryptionKey: false
 
-# If set, use an existing Kubernetes secret that contains ENCRYPTION_KEY
+# If set, the chart renders no Secret of its own and instead reads every secret env
+# var from this existing Kubernetes secret. Expected keys: ENCRYPTION_KEY (rename via
+# existingSecretKey), ADMIN_EMAIL, ADMIN_PASSWORD, OIDC_CLIENT_SECRET,
+# UNSPLASH_ACCESS_KEY, AMAP_API_KEY, AMAP_API_SECRET. Missing keys are simply left
+# unset (they are optional), so only provide the ones your setup needs.
 existingSecret: ""
 existingSecretKey: ENCRYPTION_KEY