fix(platform): terminology, branding, and typo cleanup pass (#2327)

* fix(platform): terminology, branding, and typo cleanup pass

- Fix vCluter → vCluster Platform typo in gitlab-ci.mdx
- Replace deprecated loft use management with vcluster platform connect management in use-api.mdx
- Replace Loft API/Loft CLI prose with vCluster Platform API/vCluster CLI in API resource pages
- Replace virtual cluster/host cluster/multi-tenancy with tenant cluster/control plane cluster/tenant isolation in prose
- Fix e.g. → for example and etc. → and so on to satisfy vale no-latinisms rule

Closes DOC-1503

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix(platform): prose polish from review feedback

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: djwfyi

platform/_partials/cluster/connect-cli.mdx

@@ -13,7 +13,7 @@ import Expander from '@site/src/components/Expander'
         vcluster platform add cluster cluster-name --display-name [display-name]
         ```
 
-        The above command automatically installs the [vCluster Platform Agent](../../administer/clusters/advanced/agent-config.mdx) in the cluster that corresponds to your current Kubernetes context. The host cluster where the vCluster Platform itself is deployed is automatically connected to the platform during installation. Therefore, this command should be executed in a different host cluster from the one where the vCluster Platform is running.
+        The above command automatically installs the [vCluster Platform Agent](../../administer/clusters/advanced/agent-config.mdx) in the cluster that corresponds to your current Kubernetes context. The control plane cluster where vCluster Platform itself is deployed is automatically connected to the platform during installation. Therefore, this command should be executed in a different cluster from the one where vCluster Platform is running.
 
         By default, the `vcluster-platform` namespace is created automatically if it does not already exist on the cluster. The vCluster Platform Agent resources are deployed into this namespace. You can override this behavior by explicitly specifying a different namespace using the `--namespace` flag. If you want to connect a cluster that is not associated with your current Kubernetes context, use the `--context` flag to specify the context of the target cluster. 
 :::info

platform/_partials/cluster/upgrade-cli.mdx

@@ -22,7 +22,7 @@ import Expander from '@site/src/components/Expander'
             cluster-name      |  7s
         ```
 
-        In this example, the host cluster where the platform agent is installed is named `cluster-name`.
+        In this example, the cluster where the platform agent is installed is named `cluster-name`.
     </Step>
     <Step>
         By providing the Helm chart version and values configuration, you can install or upgrade the existing platform agent deployment for the `cluster-name` cluster using:

platform/_partials/cluster/upgrade-helm.mdx

@@ -22,7 +22,7 @@ import Expander from '@site/src/components/Expander'
         14:43:35 info vCluster platform host: https://loftg2fei.loft.host
         14:43:35 info Access Key: xxxxxxxx
         ```
-        In this example, `cluster-name` refers to the host cluster containing the [vCluster Platform Agent](../../administer/clusters/advanced/agent-config.mdx) to be upgraded.
+        In this example, `cluster-name` refers to the cluster containing the [vCluster Platform Agent](../../administer/clusters/advanced/agent-config.mdx) to be upgraded.
 
         <!-- vale off -->
         Here, `https://loftg2fei.loft.host` represents the `url`, and `xxxxxxxx` is the `token`.
@@ -54,7 +54,7 @@ import Expander from '@site/src/components/Expander'
         Platform Helm values, merged with any cluster-specific overrides from the `loft.sh/agent-values` annotation (when present).
 
         If the platform agent is not yet installed, you can include the `--install` and `--create-namespace` flags. The combination 
-        of `--create-namespace` and `--namespace vcluster-platform` will create the `vcluster-platform` namespace in the host cluster
+        of `--create-namespace` and `--namespace vcluster-platform` will create the `vcluster-platform` namespace in the control plane cluster
         if it does not already exist. All platform agent resources will then be deployed and run within that namespace.
     </Step>
 </Flow>

platform/administer/clusters/advanced/multi-region/overview.mdx

@@ -105,12 +105,12 @@ installation. See [Deploy (AWS/EKS)](./deploy.mdx) for step-by-step setup instru
 
 Multi-region platforms run an embedded Kubernetes API server inside each
 region's vCluster Platform pod. The `v1.management.loft.sh` aggregated
-APIService isn't registered on the host EKS cluster. Each region registers it
+APIService isn't registered on the control plane EKS cluster. Each region registers it
 inside its own embedded API server instead. This changes how automation and
 integrations such as Argo CD or Terraform call the management API.
 
-The aggregated APIService is cluster-scoped, so a single host EKS cluster can
-register only one. With multiple region pods sharing the same host cluster,
+The aggregated APIService is cluster-scoped, so a single control plane EKS cluster can
+register only one. With multiple region pods sharing the same control plane cluster,
 that one registration can't route correctly to all of them. Each region
 therefore registers the APIService locally, and the platform's own HTTPS
 endpoint is the integration surface.

platform/api/resources/directclusterendpointtoken.mdx

@@ -5,7 +5,7 @@ sidebar_label: Direct Cluster Endpoint Token
 import Reference from "../_partials/resources/directclusterendpointtokens/reference.mdx"
 import Create from "../_partials/resources/directclusterendpointtokens/create.mdx"
 
-Direct Cluster Endpoints are a feature to avoid the central Loft instance and directly connect to a connected Loft cluster.
+Direct Cluster Endpoints allow you to avoid routing through the central vCluster Platform instance and directly connect to a connected cluster.
 
 ## Direct Cluster Endpoint Token example
 

platform/api/resources/ownedaccesskey.mdx

@@ -7,7 +7,7 @@ import Create from "../_partials/resources/ownedaccesskeys/create.mdx"
 import Update from "../_partials/resources/ownedaccesskeys/update.mdx"
 import Delete from "../_partials/resources/ownedaccesskeys/delete.mdx"
 
-Access keys let you authenticate with Loft API endpoints and Loft CLI in non-interactive environments such as from within CI/CD pipelines.
+Access keys let you authenticate with vCluster Platform API endpoints and the vCluster CLI in non-interactive environments such as from within CI/CD pipelines.
 
 ## Owned Access Key example
 

platform/api/resources/sharedsecret.mdx

@@ -8,7 +8,7 @@ import Create from "../_partials/resources/sharedsecrets/create.mdx"
 import Update from "../_partials/resources/sharedsecrets/update.mdx"
 import Delete from "../_partials/resources/sharedsecrets/delete.mdx"
 
-Global Secrets can be used to share sensitive information across users, teams and connected clusters. You can either access shared secrets through the Loft CLI or sync them directly to a project secret.
+Global Secrets can be used to share sensitive information across users, teams, and connected clusters. You can access shared secrets through the vCluster CLI or sync them directly to a project secret.
 
 ## Global Secret example
 

platform/api/resources/virtualclusterinstance/virtualclusterinstance.mdx

@@ -8,7 +8,7 @@ import Create from "../../_partials/resources/virtualclusterinstances/create.mdx
 import Update from "../../_partials/resources/virtualclusterinstances/update.mdx"
 import Delete from "../../_partials/resources/virtualclusterinstances/delete.mdx"
 
-A virtual cluster is a fully functional Kubernetes cluster that runs inside the namespace of another Kubernetes cluster (host cluster). Virtual clusters are very useful if you are hitting the limits of namespaces and do not want to make special exceptions to the multi-tenancy configuration of the underlying cluster, e.g. a user needs their own CRD or user needs pods from 2 namespaces to communicate with each other but your standard NetworkPolicy does not allow this, then a virtual cluster may be perfect for this user.
+A tenant cluster is a fully functional Kubernetes cluster that runs inside the namespace of a control plane cluster. Tenant clusters are a good fit when you hit the limits of namespaces and want to avoid making special exceptions to the tenant isolation configuration of the underlying cluster. Common use cases include a user who needs their own CRDs or their own pods across different namespaces that need to communicate beyond what your standard NetworkPolicy allows.
 
 ## Virtual Cluster example
 

platform/api/use-api.mdx

@@ -7,7 +7,7 @@ sidebar_position: 2
 The vCluster platform management API is a Kubernetes API server that only serves virtual resources (not persisted in etcd) that facilitate interaction with vCluster platform.
 These resources are primarily used by the UI and CLI to change state in the Kubernetes cluster where vCluster platform is installed in, without the need to have cluster wide access.
 
-In order to access the vCluster platform management api, you'll need a vCluster platform access key. See [access keys](../administer/authentication/access-keys) for more information how to create a new access key.
+In order to access the vCluster Platform management API, you'll need a vCluster Platform access key. See [access keys](../administer/authentication/access-keys) for more information how to create a new access key.
 
 After you have obtained an access key, login into vCluster platform and connect to the management API:
 
@@ -26,7 +26,7 @@ To view what resources are available in the management API Kubernetes server, yo
 
 ## Optional: Connect to the Kubernetes Cluster vCluster platform is installed in
 
-Since the vCluster platform API server doesn't contain resources such as `pods`, `services` etc., some tools get confused and won't work with the vCluster platform API server directly (such as ArgoCD). Instead of using `loft use management` to access the resources, you can run the following command instead:
+Since the vCluster Platform API server doesn't contain resources such as `pods`, `services`, and so on, some tools get confused and won't work with the vCluster Platform API server directly (such as ArgoCD). Instead of using `vcluster platform connect management` to access the resources, you can run the following command instead:
 
 ```
 # Get a context to the cluster where loft is installed in instead
@@ -39,4 +39,4 @@ kubectl get users.management.loft.sh
 kubectl get pods
 ```
 
-The main difference between this approach and `vcluster platform connect management` is that all requests are routed through an actual Kubernetes cluster, which can be wanted if other resources are needed, but also expose all APIs to the requester, which is why we recommend to use `loft use management` if possible.
+The main difference between this approach and `vcluster platform connect management` is that all requests are routed through an actual Kubernetes cluster, which can be wanted if other resources are needed, but also expose all APIs to the requester, which is why we recommend to use `vcluster platform connect management` if possible.

platform/integrations/argocd/deploy-applications.mdx

@@ -285,7 +285,7 @@ Setting `target: host` deploys the application onto the control plane cluster ra
 
 - **Who controls the tenant cluster configuration?** If tenants can edit `vcluster.yaml` directly, they can deploy arbitrary workloads onto the control plane cluster. Restrict this to platform admins or use cluster templates to limit what values tenants can set.
 - **The control plane cluster must have a connector.** If the control plane cluster does not have an Argo CD connector configured, applications with `target: host` will fail to deploy.
-- **Applications are deployed into a specific namespace.** The `destination.namespace` in the argoCDApplication field determines where the application lands on the control plane cluster. Ensure that deploying in that namespace wouldn't cause any disruption on the host cluster.
+- **Applications deploy into a specific namespace.** The `destination.namespace` in the argoCDApplication field determines where the application lands on the control plane cluster. Ensure that deploying in that namespace wouldn't cause any disruption on the control plane cluster.
 
 This is a platform-admin-level capability. Do not expose it to end users without proper guardrails.
 :::