fix: remove references to autoGenerated secrets and add RDBMS secret in table

Signed-off-by: Jesse Simpson <jesse.simpson@camunda.com>

Author: jessesimpson36

docs/self-managed/deployment/helm/configure/secret-management.md

@@ -60,6 +60,7 @@ These secrets are used by Camunda applications and external integrations. Config
 | **SMTP Password**                         | `webModeler.restapi.mail.secret`                    | External   | SMTP credentials for sending email notifications                         |
 | **External Elasticsearch Auth**           | `global.elasticsearch.auth.secret`                  | External   | Password for external Elasticsearch authentication (basic auth)          |
 | **External OpenSearch Auth**              | `global.opensearch.auth.secret`                     | External   | Password for external OpenSearch authentication (basic auth)             |
+| **RDBMS Auth**                            | `orchestration.data.secondaryStorage.rdbms.secret`  | External   | Password for external RDBMS authentication (basic auth)                  |
 
 ### Secrets using Bitnami subchart patterns
 
@@ -174,35 +175,6 @@ webModelerPostgresql:
       userPasswordKey: web-modeler-postgresql-user-password
 ```
 
-### Auto-generated secrets
-
-The Helm chart can automatically generate secrets with random passwords for both development and production environments. This removes the need to create secrets manually during initial setup. You can enable this feature during installation by setting `--set global.secrets.autoGenerated=true`.
-
-### Important limitations
-
-The auto-generated secret uses Helm hooks (`pre-install`) with a `keep` resource policy. This means:
-
-- The secret is created before the main Helm release installation.
-- The secret is not managed by later Helm operations (upgrade, rollback, uninstall).
-- If you delete the secret, generated passwords are lost permanently.
-- The secret becomes orphaned from the Helm release lifecycle.
-
-### Configuring components to use auto-generated secrets
-
-Enabling `global.secrets.autoGenerated: true` only creates the secret with random values. You must configure each component to reference the auto-generated secret by name and key. The key can be custom, but the name must match the definition above.
-
-```yaml
-connectors:
-  security:
-    authentication:
-      oidc:
-        secret:
-          existingSecret: "camunda-credentials"
-          existingSecretKey: "identity-connectors-client-token"
-```
-
-For details on Identity secrets during installation, see the [installation guide](/self-managed/deployment/helm/install/quick-install.md#create-identity-secrets).
-
 ## Document Store secrets
 
 Document Store secrets use the structured `secret:` pattern with separate secret configurations for each credential component.
@@ -292,7 +264,7 @@ You can use a single consolidated secret (e.g., app-credentials) or one secret p
 
 ### Find any plaintext secrets in your `values.yaml`
 
-#### A - If the secrets already exist in Kubernetes (e.g. autogenerated via chart)
+#### A - If the secrets already exist in Kubernetes
 
 You can read the current (base64-encoded) data from existing secrets and reuse it in your new consolidated secret.