searxng: state the limiter probe measurement instead of hedging it

The comment on the probe block said a probe on "/" would "risk" a 429 once
the limiter is on. It was measured against a reachable Valkey in k3d and it
does not risk it, it collects one: "/" answered 429 while /healthz answered
200. Comment only, no rendered change.

searxng/values.yaml

@@ -187,10 +187,13 @@ searxng:
   #
   # For it: /healthz is the ONLY path SearXNG's bot detection lets through
   # unconditionally - searx/limiter.py filter_request() returns early on
-  # exactly this path before any of its checks run. A probe on "/" would risk
+  # exactly this path before any of its checks run. This is not a theoretical
-  # collecting a 429 the moment settings.limiter is switched on; the pod would
+  # margin. Measured in k3d against a reachable Valkey with settings.limiter
-  # go NotReady and the symptom would point at the application instead of at
+  # true: "/" answered 429 while /healthz answered 200. A probe on "/" would
-  # the bot detection. It also costs nothing: the handler is
+  # therefore not merely risk a 429, it would collect one the moment the
+  # limiter is switched on - the pod would go NotReady and the symptom would
+  # point at the application instead of at the bot detection. It also costs
+  # nothing: the handler is
   # `return Response('OK', mimetype='text/plain')`, no engines, no cache, no
   # network - so liveness carries no external dependency (README, "Values that
   # must not lie", point 3).