velero: document the single-node assumption in kube_discovery

The agent pod is pinned to its own node via
DD_KUBERNETES_KUBELET_HOST/NODENAME, correct Kubelet-AD semantics, but it
means this helper only produces complete results when discovery targets
share a node with the agent pod. That holds for velero's single-node
kind cluster today, but the module bills itself as generic scaffolding
for future kind-based integrations without mentioning the constraint.
Document it so a future multi-node adopter doesn't have to rediscover it
from a flaky failure.

Environment: Datadog workspace

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

Author: vitkyrka

datadog_checks_dev/datadog_checks/dev/kube_discovery.py

@@ -7,6 +7,11 @@
 ``kubectl exec`` against a sleeping, RBAC-scoped Agent pod, rather than a normal long-running Agent.
 There is no Kubernetes equivalent of ``mount_logs``/``shared_logs()`` here: there is no host
 bind-mount channel into a cluster pod.
+
+The agent pod is pinned to its own node (see the ``DD_KUBERNETES_KUBELET_HOST``/``NODENAME`` env
+vars in ``build_agent_pod_manifest``), matching real Kubelet-AD semantics: it only sees pods
+scheduled on that same node. This assumes a single-node ``kind`` cluster, or that discovery targets
+are pinned to the same node as the agent pod.
 """
 
 import json