vector_search: test: fix flaky test_dns_resolving_repeated

Move trigger_dns_resolver() inside the repeat_until loop instead of
calling it once before the loop.

The test was intermittently timing out on CI. The exact root cause is not
fully understood, but the hypothesis is that a single trigger signal can
be lost somewhere (not exactly known where). This is not an issue for the
production code because refresh trigger will be called multiple times -
in every query where all configured nodes will be unreachable.

By triggering inside the loop, we ensure the signal is re-sent on
each iteration until the resolver actually performs the refresh and
picks up the new (failing) DNS resolution. This makes the test
resilient to timing-dependent signal loss without changing production
code.

Fixes: SCYLLADB-1794
(cherry picked from commit 4722be1289)

test/vector_search/vector_store_client_test.cc

@@ -193,12 +193,11 @@ SEASTAR_TEST_CASE(vector_store_client_test_dns_resolving_repeated) {
     BOOST_CHECK_EQUAL(print_addr(addrs1[0]), "127.0.0.1");
 
     fail_dns_resolution = true;
-    // Trigger DNS resolver to check for address changes
-    // Resolver will not re-check automatically after successful resolution
-    vector_store_client_tester::trigger_dns_resolver(vs);
 
-    // Wait for the DNS resolution to fail again
+    // Wait for the DNS resolution to fail again.
+    // Trigger is called inside the loop to mitigate SCYLLADB-1794.
     BOOST_CHECK(co_await repeat_until(seconds(1), [&vs, &as]() -> future<bool> {
+        vector_store_client_tester::trigger_dns_resolver(vs);
         auto addrs = co_await vector_store_client_tester::resolve_hostname(vs, as.reset());
         co_return addrs.empty();
     }));