docs: import CloudNativePG main

Author: cnpg-bot

website/docs/cnpg_i.md

@@ -41,7 +41,7 @@ CNPG-I is inspired by the Kubernetes
 The operator communicates with registered plugins using **gRPC**, following the
 [CNPG-I protocol](https://github.com/cloudnative-pg/cnpg-i/blob/main/docs/protocol.md).
 
-CloudNativePG discovers plugins **at startup**. You can register them in one of two ways:
+You can register plugins in one of two ways:
 
 - Sidecar container – run the plugin inside the operator’s Deployment
 - Standalone Deployment – run the plugin as a separate workload in the same
@@ -51,7 +51,9 @@ In both cases, the plugin must be packaged as a container image.
 
 ### Sidecar Container
 
-When running as a sidecar, the plugin must expose its gRPC server via a **Unix
+Sidecar plugins are discovered once at operator startup.
+
+The plugin must expose its gRPC server via a **Unix
 domain socket**. This socket must be placed in a directory shared with the
 operator container, mounted at the path set in `PLUGIN_SOCKET_DIR` (default:
 `/plugin`).
@@ -89,11 +91,8 @@ spec:
 Running a plugin as its own Deployment decouples its lifecycle from the
 operator’s and allows independent scaling. In this setup, the plugin exposes a
 TCP gRPC endpoint behind a Service, with **mTLS** for secure communication.
-
-:::warning
-    CloudNativePG does **not** discover plugins dynamically. If you deploy a new
-    plugin, you must **restart the operator** to detect it.
-:::
+Standalone plugins are discovered dynamically by watching for Services with the
+required labels and annotations — no operator restart is needed.
 
 Example Deployment: