docs(self-managed): migrate Helm datastore config off removed global elasticsearch and opensearch keys

[bkenez]

Description

camunda-platform chart 15.x (Camunda 8.10) removes the deprecated global.elasticsearch.* and global.opensearch.* value trees (deprecated in 8.9; removal in camunda/camunda-platform-helm#6914). Setting any key under them now fails helm install/helm upgrade with an error naming the replacement.

This PR updates the unversioned (8.10) docs accordingly:

• upgrade/helm/890-to-8100.md: replaces the two per-leaf tls.existingSecret rows with whole-tree rows and adds a full migration mapping table (optimize.database.*, orchestration.data.secondaryStorage.*, JKS password path, clusterName, prefix).
• upgrade/prepare-for-upgrade.md: corrects the 8.10 rows that said the keys are "deprecated in 8.10 ... Legacy keys still work in 8.10" and that instructed setting global.elasticsearch.enabled: true / elasticsearch.enabled: true (neither key exists in the 8.10 chart).
• components/orchestration-cluster/core-settings/configuration/partials/_secondary-storage.md: the Helm values tab now teaches the component-scoped keys.
• deployment/helm/configure/database/elasticsearch/configure-elasticsearch-prefix-indices.md, deployment/helm/configure/secret-management.md, deployment/helm/configure/tls.md, deployment/helm/install/production/index.md: tables and examples migrated to the component-scoped keys.\n- concepts/secondary-storage/configuring-secondary-storage.md: the Elasticsearch example now uses the Orchestration secondary-storage block.\n- deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md: removes the obsolete bundled-Elasticsearch path and points to ECK.\n- deployment/helm/configure/authentication-and-authorization/microsoft-entra.md: the full example configures both consumers against external Elasticsearch.

Versioned docs (8.7-8.9) are untouched — the keys remain valid there.

closes camunda/camunda-platform-helm#6918

When should this change go live?

• This is part of a scheduled alpha or minor. (add alpha or minor label)

PR Checklist

• The commit history of this PR is cleaned up, using {type}(scope): {description} commit message(s)
• My changes are for an upcoming minor release and are in the /docs directory.
• I added a DRI, team, or delegate as a reviewer for technical accuracy and grammar/style:
  • Engineering team review
  • Technical writer review via @camunda/tech-writers unless working with an embedded writer.

[github-actions]

👋 🤖 🤔 Hello, @bkenez! Did you make your changes in all the right places?

These files were changed only in docs/. You might want to duplicate these changes in versioned_docs/version-8.9/.

• docs/self-managed/components/orchestration-cluster/core-settings/configuration/partials/_secondary-storage.md
• docs/self-managed/concepts/secondary-storage/configuring-secondary-storage.md
• docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md
• docs/self-managed/deployment/helm/configure/authentication-and-authorization/microsoft-entra.md
• docs/self-managed/deployment/helm/configure/database/elasticsearch/configure-elasticsearch-prefix-indices.md
• docs/self-managed/deployment/helm/configure/database/elasticsearch/using-external-elasticsearch.md
• docs/self-managed/deployment/helm/configure/secret-management.md
• docs/self-managed/deployment/helm/configure/tls.md
• docs/self-managed/deployment/helm/install/production/index.md
• docs/self-managed/upgrade/helm/890-to-8100.md
• docs/self-managed/upgrade/prepare-for-upgrade.md

You may have done this intentionally, but we wanted to point it out in case you didn't. You can read more about the versioning within our docs in our documentation guidelines.

[infraex-misc]

🔍 InfraEx Content Detected

This PR modifies documentation pages owned or referenced by the Infrastructure Experience team.

A review from @camunda/infraex-medic has been requested to ensure technical consistency.

📎 Files referencing monitored repos

File
docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md

---

ℹ️ What to check

• Link validity: Do links still point to existing files/branches?
• Technical accuracy: Are references consistent with the deployment repo?
• Version alignment: Do version-specific docs match the release branch?
• Architecture consistency: Do changes align with the reference architecture?

Auto-generated by InfraEx Docs PR Watcher.