Private connectivity pages omit the remote cluster ports (9400/9443), and the AWS security group guidance blocks them

## Problem

All three private connectivity pages tell readers that only ports `443` and `9243` are supported into an Elastic Cloud Hosted deployment over a private connection. Remote cluster traffic for cross-cluster search and cross-cluster replication uses port `9400` with the TLS certificate based security model, or `9443` with the API key based model. That path is supported when the local cluster runs in your own VPC or VNet. None of the three pages mention it.

This contradicts [Remote clusters](https://www.elastic.co/docs/deploy-manage/remote-clusters#remote-clusters-and-network-security), which already documents the path as supported:

> | Local cluster location | Remote cluster | Connection path | Private connectivity applicable? |
> | --- | --- | --- | --- |
> | Self-managed or Elastic Cloud Enterprise cluster in your VPC or VNet | Elastic Cloud Hosted deployment | Public proxy address, or a private connection: create a VPC Endpoint (AWS), Private Endpoint (Azure), or Private Service Connect endpoint (GCP) and connect to the remote cluster through it. | Yes (in this direction only). |

and states:

> remote clusters with API key–based authentication use port `9443` by default

So the remote clusters page is correct and the private connectivity setup pages are behind it. A reader who starts from the setup pages, which is the natural entry point when configuring a private endpoint, has no way to learn that the remote cluster ports are usable.

## Affected locations

| Page | Instances | Current text |
| --- | --- | --- |
| [Private connectivity with AWS](https://www.elastic.co/docs/deploy-manage/security/private-connectivity-aws) | 2, plus the security group guidance below | "Elastic Cloud Hosted supports ports 443 and 9243." |
| [Private connectivity with Azure](https://www.elastic.co/docs/deploy-manage/security/private-connectivity-azure) | 2 | same |
| [Private connectivity with GCP](https://www.elastic.co/docs/deploy-manage/security/private-connectivity-gcp) | 1 | same |

The AWS page carries a more serious instance, because this one drives configuration rather than just describing it:

> The security group for the endpoint should, at minimum, allow for inbound connectivity from your instances' CIDR range on ports 443 and 9243. Security groups for the instances should allow for outbound connectivity to the endpoint on ports 443 and 9243.

A reader who follows that builds a security group which silently drops remote cluster traffic. This is not only an omission, it is guidance that produces a broken configuration and a failure that is hard to diagnose from the client side.

## Suggested wording

For the port notes on all three pages:

> Elastic Cloud Hosted supports ports `443` and `9243` for Elasticsearch and Kibana traffic. Remote cluster traffic for cross-cluster search and cross-cluster replication uses port `9400` with the TLS certificate based security model, or `9443` with the API key based model. Refer to [Connection paths and private connectivity](https://www.elastic.co/docs/deploy-manage/remote-clusters#remote-clusters-and-network-security) for the supported combinations.

For the AWS security group paragraph, add a sentence:

> If you use this endpoint for remote cluster traffic, also allow port `9400` or `9443`, depending on the security model you configure.

## Please leave the Serverless notes as they are

The neighbouring Serverless notes ("Elastic Cloud Serverless supports port 443") are correct and should stay. Remote clusters are not available in Elastic Cloud Serverless; cross-project search is the equivalent and does not require remote cluster configuration. Flagging so they don't get changed for symmetry.

## One dependency

The Azure wording is pending internal confirmation that `9443` is reachable over Azure Private Link (tracked internally at `elastic/ecp-traffic-team#2941`). AWS and GCP can go ahead now. I'll confirm the Azure detail here once I have it, so please treat the Azure page as a follow-up rather than blocking the other two.

## Origin

A customer attempted cross-cluster search from an Elastic Cloud on Kubernetes cluster into an Elastic Cloud Hosted deployment over a private connection, and it failed. Neither the customer nor support could determine from these pages whether the path was supported at all.