doc: clarify cluster registration wording and fix prose issues in overview and connect-argocd pages

Author: flomedja

platform/integrations/argocd/connect-argocd.mdx

@@ -151,7 +151,7 @@ stringData:
 
 ### On a tenant cluster
 
-Add the `integrations.argoCD` block to the tenant cluster's `vcluster.yaml`. The `connector` field references the Secret name from Step 1.
+Add the `integrations.argoCD` block to the tenant cluster's `vcluster.yaml`. The `connector` field references the Secret name from [Step 1](#step-1-create-a-connector).
 
 ```yaml
 integrations:

platform/integrations/argocd/deploy-applications.mdx

@@ -31,7 +31,7 @@ An `ArgoCDApplicationTemplate` is a reusable Argo CD ApplicationSpec. Create one
 
 <Flow>
   <Step>
-    Click <Label>Templates</Label> in the left sidebar, then select <Label>Argo CD Templates</Label>.
+    Click <Label>Argo CD Templates</Label> in the left sidebar.
   </Step>
   <Step>
     Click <Button>Add ArgoCD Application Template</Button>.

platform/integrations/argocd/overview.mdx

@@ -27,10 +27,12 @@ A single connector can be referenced by many clusters. You create it once and re
 
 ### Cluster registration
 
-When a tenant cluster or control plane cluster references a connector, Platform registers it as a destination cluster in Argo CD using the Platform proxy as the API server endpoint and a scoped access key as the bearer token. This means:
+When a tenant cluster or control plane cluster references a connector, Platform registers that cluster as
+a destination in Argo CD. The registration uses the Platform proxy as the API server endpoint and a 
+scoped access key as the bearer token. This means:
 
 - The cluster's Kubernetes API server does not need to be publicly reachable from Argo CD.
-- Access is scoped per cluster — Argo CD uses the Platform-issued access key, not a long-lived kubeconfig.
+- Access is scoped per cluster. Argo CD authenticates using a Platform-issued access key, not a long-lived kubeconfig.
 - When a tenant cluster is deleted or the integration is disabled, Platform deregisters it from Argo CD automatically.
 
 For Akuity, registration also provisions an agent inside the cluster (see [Connect to Akuity](./connect-akuity.mdx) for details).
@@ -39,15 +41,15 @@ For Akuity, registration also provisions an agent inside the cluster (see [Conne
 
 The integration introduces two Platform-level resources:
 
-- **`ArgoCDApplication`**: Represents a single Argo CD application with a vCluster-aware destination type — either the tenant cluster itself (`vcluster`) or the control plane cluster it runs on (`host`). Platform reconciles these into actual Argo CD Application objects.
-- **`ArgoCDApplicationTemplate`**: A reusable Argo CD ApplicationSpec with named parameters. Templates allow the same application definition to be referenced across many tenant clusters without duplication.
+- **`ArgoCDApplication`**: Represents an Argo CD application targeted at either the tenant cluster (`vcluster`) or its control plane cluster (`host`). Platform creates the corresponding Argo CD Application object and keeps it in sync
+- **`ArgoCDApplicationTemplate`**: A reusable Argo CD ApplicationSpec with named parameters. Templates allow the same application definition to be referenced across many tenant clusters and control plane clusters without duplication.
 
 These resources live in the Platform project namespace and are managed by Platform, not by Argo CD directly.
 
 ## Standard Argo CD vs Akuity
 
-Use the standard Argo CD integration when you operate your own Argo CD server and want direct API access. Use Akuity when you use Akuity's managed Argo CD service, which uses an in-cluster agent rather than direct API server access.
-
+Use the standard Argo CD integration if you run your own Argo CD server. 
+Choose the Akuity integration if your Argo CD instance is managed by Akuity. Akuity connects to clusters through an in-cluster agent rather than direct API access. 
 | | Standard Argo CD | Akuity |
 |---|---|---|
 | Argo CD hosting | Self-hosted | Akuity-managed |