Fix Zookeeper startup wait logic in StartZookeeperWindowsProcessor

[SURYAS1306]

Fixes #16085

What is the purpose of the change?

The Windows Zookeeper startup logic currently relies on a fixed sleep:

TimeUnit.SECONDS.sleep(3);

This is unreliable because Zookeeper startup time varies depending on machine
performance and environment. As a result, tests may randomly fail when the
server is not fully ready after the fixed delay.

This PR replaces the fixed delay with an active readiness check using
CuratorFramework.blockUntilConnected(). The processor now waits until the
Zookeeper instance is actually reachable before continuing.

This makes the test startup deterministic and removes flaky behavior.

Brief changelog

• Remove fixed 3-second sleep
• Add Curator-based readiness check
• Wait for each client port to become available
• Improve Windows test stability

Verifying this change

• Project builds successfully
• Module dubbo-test-check compiles
• No behavior change except improved stability
• Prevents intermittent startup failures

Checklist

• Make sure there is a GitHub issue field for the change.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• No new feature introduced
• Code style and format verified (spotless applied)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.79%. Comparing base (06334a5) to head (1e39663).

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16086      +/-   ##
============================================
- Coverage     60.80%   60.79%   -0.02%     
- Complexity    11750    11762      +12     
============================================
  Files          1953     1953              
  Lines         89121    89121              
  Branches      13443    13443              
============================================
- Hits          54192    54180      -12     
- Misses        29369    29377       +8     
- Partials       5560     5564       +4     

Flag	Coverage Δ
integration-tests-java21	32.18% <ø> (+<0.01%)	⬆️
integration-tests-java8	32.28% <ø> (+0.03%)	⬆️
samples-tests-java21	32.11% <ø> (-0.07%)	⬇️
samples-tests-java8	29.76% <ø> (+0.01%)	⬆️
unit-tests-java11	59.07% <ø> (+<0.01%)	⬆️
unit-tests-java17	58.54% <ø> (-0.03%)	⬇️
unit-tests-java21	58.54% <ø> (-0.02%)	⬇️
unit-tests-java25	58.53% <ø> (+0.01%)	⬆️
unit-tests-java8	59.07% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[LI123456mo]

Thanks for the PR! I've taken a look at the logic, and it seems to solve the 'ugly sleep' problem I reported in #16085 by using a proactive Curator check.

Since I'm still getting familiar with the project's internal standards, could @zrlw, @AlbumenJ , @heliang666s or any other maintainer please take a quick look to ensure the Curator configuration (timeouts/retry policy) aligns with the best practices?