docs: clarify absolute delay limitation

Author: ku524

docs/operator_configuration.md

@@ -235,12 +235,13 @@ host.
 
 The existing caught-up marker path remains unchanged when this gate is disabled. That
 path only polls the local host's `MAX(absolute_delay)` from `system.replicas` before
-writing `status.hostsWithReplicaCaughtUp`. During recreated-host recovery, that value
-can be an incomplete proxy: asynchronous database/table loading may not have exposed
-all replicated objects on the local host yet, and a local delay metric cannot discover
-replicated objects that exist on peers or issue a ClickHouse sync barrier for their
-known parts. The sync gate adds those checks before the operator advances to the next
-host.
+writing `status.hostsWithReplicaCaughtUp`, which is weak for recreated-host recovery
+because the metric is limited to replicated objects already loaded and visible on that
+local server. During recreated-host recovery, asynchronous database/table loading may
+not have exposed all replicated objects on the local host yet, and a local delay metric
+cannot discover replicated objects that exist on peers or issue a ClickHouse sync
+barrier for their known parts. The sync gate adds those checks before the operator
+advances to the next host.
 
 ```yaml
 spec: