refactor(configure): align with PR #764 IPI/UPI/Kamaji terms

Post-rebase sweep to carry forward the terminology spec (PPI -> IPI;
Kamaji impl note for HCP) into Configure pages and refresh stale
llms.txt paths for the new Configure tree.

- configure/hosted_control_planes/overview.mdx: replace
  "Platform-Provisioned Infrastructure" with
  "Installer-Provisioned Infrastructure (IPI)"; add the
  "implemented through Kamaji (\`TenantControlPlane\`)" clause on
  the page's first HCP mention.
- configure/storage/cosi/cosi-concepts.mdx and intro.mdx: adopt the
  cleaner reader-task framing from the original PR #795 wording
  while keeping the MinIO removal already applied on master.
- llms.txt: mechanically rewrite 43 entries to the new Configure
  paths (clusters/nodes -> nodes, clusters/etcd-encryption ->
  etcd/encryption, configure/networking -> networking,
  developer/registry -> configure/registry,
  configure/notification/cluster_notification ->
  observability/alerting/notification, etc.) and remove 4 entries
  for files deleted by either PR. Full llms.txt regeneration for
  newly added Configure pages remains a follow-up under the
  llmstxt-generator workflow.

References: ACP terminology spec v0.8 sec 3.1 axis 1, sec 4.1, sec 9.2;
shared ledger TW-001, TW-011, TW-013 (updated 2026-05-19).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: youyongsong

docs/en/configure/hosted_control_planes/overview.mdx

@@ -4,8 +4,8 @@ weight: 10
 
 # Overview
 
-Hosted Control Plane (HCP) is a control-plane topology. Each hosted cluster has its own control plane, and multiple hosted control planes run as workloads on a management cluster.
+Hosted Control Plane (HCP) is a control-plane topology. Each hosted cluster has its own control plane, and multiple hosted control planes run as workloads on a management cluster. In <Term name="productShort" />, HCP is implemented through Kamaji (`TenantControlPlane`).
 
-In <Term name="productShort" /> 4.3, HCP is Technology Preview, is not production-supported, supports disconnected environments, and defaults to Platform-Provisioned Infrastructure only. Use HCP for non-production evaluation only. For installation and operation tasks within that scope, follow the HCP guidance below.
+In <Term name="productShort" /> 4.3, HCP is Technology Preview, is not production-supported, supports disconnected environments, and defaults to Installer-Provisioned Infrastructure (IPI) only. Use HCP for non-production evaluation only. For installation and operation tasks within that scope, follow the HCP guidance below.
 
 <ExternalSite name="hosted-control-plane" />

docs/en/configure/storage/cosi/cosi-concepts.mdx

@@ -6,9 +6,9 @@ weight: 20
 
 ## Overview
 
-This document introduces Kubernetes administrators familiar with persistent storage concepts to the core resources and principles of the Container Object Storage Interface (COSI). COSI provides a declarative mechanism for managing object storage such as Ceph RGW, similar to existing Kubernetes persistent storage management approaches.
+Kubernetes administrators who are familiar with persistent storage concepts can use Container Object Storage Interface (COSI) resources to manage object storage through declarative Kubernetes APIs. COSI provides a declarative mechanism for managing object storage, similar to existing Kubernetes persistent storage management approaches.
 
-We will cover the three primary resources in COSI—**BucketClass, Bucket, and BucketClaim**—drawing analogies with Kubernetes storage resources to clarify their relationships and functionalities.
+COSI uses three primary resources: **BucketClass**, **Bucket**, and **BucketClaim**.
 
 ## Core Resources
 
@@ -46,7 +46,7 @@ parameters:
 **Scope:** Cluster-scoped
 **Analogous Kubernetes Concept:** Similar to PersistentVolume (PV)
 
-Bucket represents an abstraction of an actual bucket present in an external object storage system such as Ceph RGW within Kubernetes.
+Bucket represents a Kubernetes abstraction of an actual bucket in an external object storage system.
 
 Lifecycle management:
 

docs/en/configure/storage/cosi/intro.mdx

@@ -4,7 +4,7 @@ weight: 10
 
 # Introduction
 
-The Container Object Storage Interface (COSI) is a Kubernetes-native framework designed to provide a standardized and declarative approach for managing object storage services such as Ceph RGW within Kubernetes clusters. COSI extends Kubernetes' storage model to support object storage resources in a way that is portable, scalable, and consistent with the principles of Kubernetes.
+The Container Object Storage Interface (COSI) is a Kubernetes-native framework for managing object storage services through standardized and declarative APIs. COSI extends the Kubernetes storage model so workloads can request object storage resources through Kubernetes-style objects.
 
 COSI enables administrators to define, provision, and consume object storage buckets through familiar Kubernetes-style APIs. It simplifies integration between applications and backend object storage systems, automating the lifecycle of buckets and their access credentials. With COSI, Kubernetes users can request object storage resources dynamically, reducing manual configuration overhead and improving operational efficiency.