docs: fix swapped Kafka/Druid examples (#1050)

Author: sweb

docs/modules/zookeeper/pages/usage_guide/isolating_clients_with_znodes.adoc

@@ -77,10 +77,10 @@ For Kafka:
 ----
 ---
 apiVersion: kafka.stackable.tech/v1alpha1
-kind: DruidCluster
+kind: KafkaCluster
 metadata:
-  name: my-druid
-  namespace: druid-ns
+  name: my-kafka
+  namespace: data
 spec:
   zookeeperConfigMapName: kafka-znode
   ...
@@ -91,13 +91,13 @@ And for Druid:
 [source,yaml]
 ----
 ---
-apiVersion: kafka.stackable.tech/v1alpha1
-kind: KafkaCluster
+apiVersion: druid.stackable.tech/v1alpha1
+kind: DruidCluster
 metadata:
-  name: my-kafka
-  namespace: data
+  name: my-druid
+  namespace: druid-ns
 spec:
-  zookeeperConfigMapName: kafka-znode
+  zookeeperConfigMapName: druid-znode
   ...
 ----
 
@@ -109,7 +109,8 @@ You can find out more about the discovery ConfigMap xref:discovery.adoc[] and th
 
 == Restoring from backups
 
-For security reasons, a unique ZNode path is generated every time the same ZookeeperZnode object is recreated, even if it has the same name.
+A unique ZNode path is generated every time the same ZookeeperZnode object is recreated, even if it has the same name.
+This prevents a recreated (or maliciously re-created) object from taking over the ZNode and data of a previous object with the same name.
 
 If a ZookeeperZnode needs to be associated with an existing ZNode path, the field `status.znodePath` can be set to the desired path.
 Note that since this is a subfield of `status`, it must explicitly be updated on the `status` subresource, and requires RBAC permissions to replace the `zookeeperznodes/status` resource.