Improve findability of Elastic SDK and client library docs across all SDK families

## Problem
Users searching for "Elastic SDK docs" or "Elastic SDK" cannot reliably find the right documentation. The problem has two layers.

First, there is a terminology mismatch. Elastic has three distinct SDK/client families, but none of them are consistently labeled "SDK" in the docs navigation or on the landing page:

- [Elasticsearch language clients](https://www.elastic.co/docs/reference/elasticsearch-clients) (Java, Python, Go, .NET, PHP, Ruby, JavaScript, Rust, Eland) — Documented as "client libraries," not SDKs
- [EDOT SDKs](https://www.elastic.co/docs/reference/opentelemetry/edot-sdks) — These do use "SDK" terminology within their own docs, but are hidden under the Ingestion tools section and not surfaced in any broader developer tooling entry point
- Elastic Cloud management tools ([cloud-sdk-go](https://github.com/elastic/cloud-sdk-go), [ECCTL](https://www.elastic.co/docs/reference/ecctl), [Terraform provider](https://registry.terraform.io/providers/elastic/ec/latest/docs)) — Not labeled as SDKs anywhere in the docs

Second, there is no disambiguation layer. A developer instrumenting an app for observability (EDOT), one building a search application (language clients), and one automating infrastructure (Cloud tools) can all start from the same "Elastic SDK" search term, but there is no entry point that routes them to the right family based on their use case. Each family is discoverable only if the user already knows Elastic's internal taxonomy.

A secondary structural issue affects the Elasticsearch language clients specifically. These docs surface in two separate locations:
- https://www.elastic.co/docs/reference/elasticsearch-clients
- https://www.elastic.co/docs/solutions/search/site-or-app/clients

With no clear canonical home and no explicit cross-linking between them, users who find one may not realize it's the authoritative entry point, or may find the other and be uncertain about which to rely on.

## Proposed solutions
1. Create a "SDKs & developer tools" landing page (or equivalent disambiguation section) that surfaces all three SDK families, including Elasticsearch language clients, EDOT SDKs, and Cloud management tools, which are organized by use case rather than by product area. This gives users a single entry point regardless of which "SDK" they're looking for.
2. Add "SDK" as a visible synonym across all three families. At minimum, this means including "SDK" in page titles, metadata, or intro copy for the Elasticsearch clients, EDOT SDKs, and the Cloud tools page. The goal is for external search and site search to surface relevant results for "Elastic SDK" queries across all families.
3. Elevate the developer tooling entry point in the main IA. Currently, all three families are buried in different sections and are difficult to find for users that unfamiliar with Elastic's internal terminology.
4. Update the docs landing page. The current tile is "Browse the Elasticsearch client libraries for Java, .NET, Python, and more." This covers only one of the three SDK families. A broader label, such as "SDKs & developer tools", with a brief description for all families would better serve users arriving with different intents.
7. Designate one page as the canonical home for the Elasticsearch client library docs, and add a clear cross-link from the other. This prevents users from landing in a dead end or questioning which page is authoritative.

## Acceptance criteria
- [ ] A single entry point exists that surfaces all three SDK/client families (Elasticsearch language clients, EDOT SDKs, Cloud management tools), organized by use case
- [ ] "SDK" or "SDKs" appears in the title, intro, or metadata of the landing page for each family
- [ ] A site search for "Elastic SDK" returns relevant results across all three families
- [ ] All three SDK families are accessible from a prominent location in the main nav
- [ ] The docs landing page tile for developer tooling covers all three families, not only Elasticsearch language clients
- [ ] One of the two Elasticsearch client library entry points is designated canonical, and the other links to it explicitly
- [ ] No broken links or duplicate canonical pages result from any of the above changes

---

## Elastic Docs AI Scoping 🤖

Docs issue scope

### Summary
The issue requests a docs IA overhaul to improve findability of all three Elastic SDK/client families (Elasticsearch language clients, EDOT SDKs, Cloud management tools) by adding a disambiguation entry point, applying "SDK" terminology consistently, elevating developer tooling in nav, and designating one canonical Elasticsearch client home. No external code PRs are linked because this is a pure docs architecture request. A review of the existing repo confirms the issue premise: the two ES client pages (`/reference/elasticsearch-clients/index.md` titled "Elasticsearch clients" and `/solutions/search/site-or-app/clients.md` titled "Client libraries") exist with no cross-link between them; EDOT SDKs live under ingestion tools/observability; and cloud management tools appear only under "Tools and APIs for Elastic Cloud" with no "SDK" label.

### Request accuracy
Accurate — the structural problems described in the issue are confirmed by the current state of the docs repo.

### Next action for author
Draft or assign work items for each acceptance criterion, starting with the canonical client page designation and cross-link (smallest concrete fix) before tackling the new disambiguation landing page.

### Impact: High

### Scope boundary
Product API reference docs, individual language client deep-dives, and EDOT SDK configuration pages do not need changes — only the navigation, landing pages, and intro copy that routes users between families.

### Recommended documentation targets

| Page | URL | Action | Impact | Confidence | Why this page? |
|------|-----|--------|--------|------------|----------------|
| Elasticsearch clients | https://www.elastic.co/docs/reference/elasticsearch-clients | Update existing page | High | High | Canonical entry point for language clients; needs "SDK" in title/intro and cross-link to the search solutions page |
| Client libraries (Search solution) | https://www.elastic.co/docs/solutions/search/site-or-app/clients | Update existing page | High | High | Duplicate entry point; should explicitly point to the canonical reference page and note its role as a task-focused companion |
| Reference landing page | https://www.elastic.co/docs/reference | Update existing page | Medium | High | Currently groups ES clients under "Elasticsearch" and EDOT under "Ingestion tools" with no cross-family SDK framing; a new "SDKs & developer tools" row or section here would surface all three families |
| Ingestion tools reference | https://www.elastic.co/docs/reference/ingestion-tools | Update existing page | Medium | High | EDOT SDKs are buried here; the intro should call them out as SDKs and link to the new disambiguation page |
| Tools and APIs for Elastic Cloud | https://www.elastic.co/docs/deploy-manage/deploy/elastic-cloud/tools-apis | Update existing page | Medium | Medium | ECCTL and Terraform provider are listed here but never labeled "SDK" or "developer tools"; a short note and link to the disambiguation entry point would close the gap |
| New SDK & developer tools disambiguation page | (to be created, e.g. `/reference/sdks-developer-tools/index.md` or as a `get-started` entry) | Create new page | High | Medium | No single entry point currently routes users across all three families by use case; acceptance criterion 1 requires this page |
| Docs landing page tile | https://www.elastic.co/docs | Review only | Medium | Low | Tile copy ("Browse the Elasticsearch client libraries...") is likely managed outside this repo; flag for the team that owns the landing page configuration |

### Recommendations

1. **Designate `/reference/elasticsearch-clients/index.md` as canonical** and add a prominent note at the top of `/solutions/search/site-or-app/clients.md` directing readers to it as the primary reference — this closes acceptance criterion 6 with minimal risk.
2. **Add "SDKs" to the title or H1 intro** of `/reference/elasticsearch-clients/index.md` (e.g., "Elasticsearch clients and SDKs") so site search matches "Elastic SDK" queries.
3. **Create a new `/reference/sdks-developer-tools/index.md`** (or equivalent) that introduces all three families by use case: search app development → language clients; app observability instrumentation → EDOT SDKs; infrastructure automation → Cloud management tools (ECCTL, Terraform). Link this page from the main nav.
4. **Update `/reference/index.md`** to add a "SDKs & developer tools" section that references all three families and links to the new disambiguation page.
5. **Update `/reference/ingestion-tools/index.md`** to explicitly call out EDOT SDKs with the "SDK" label and link to the new disambiguation page.
6. **Update `/deploy-manage/deploy/elastic-cloud/tools-apis.md`** intro to reference ECCTL and the Terraform provider as "Cloud management SDKs/tools" and link to the disambiguation page.
7. **Flag the docs landing page tile** to whoever owns the landing page config — the current tile text covers only language clients.

### Notes

- Items 1–2 are the smallest viable changes and should be done first regardless of whether the larger disambiguation page lands.
- The new disambiguation page (item 3) is an overview/index content type — it should orient users by use case, not repeat reference content.
- Nav changes (item 3) will likely need follow-on work for `toc.yml` entries and any redirects if pages are relocated.
- The docs landing page tile (item 7) may be managed in a separate config or content repo — verify before treating it as blocked.

---
[Docs automation](https://github.com/elastic/docs-actions) | [From workflow: Issue Scope Analyzer](https://github.com/elastic/docs-content/actions/runs/24522932257)

React with 👍 if helpful, 👎 if not.