refactor: compute probe pacing from fresh clock reads - #1888

Summary

Rework the probe pacing loop in async_check_service so the wait arithmetic uses fresh clock reads. The old loop reused a now cached before the previous send, so each probe went out late by the time spent sending, and the counter reset dance across i/now/next_time was hard to follow.

Details

• Probes stay _CHECK_TIME apart on an absolute schedule (next_probe_at += _CHECK_TIME), matching the RFC 6762 section 8.1 probe interval; the wait is now computed against the current clock, so sends land on schedule instead of accumulating per-iteration lag.
• Behavior is otherwise unchanged: a conflicting cached record still raises NonUniqueNameException or renames and restarts probing from zero, and every wake from async_wait (which record updates notify) re-checks for a conflict before waiting again.
• The nested conflict while is flattened to an if/continue since the outer loop re-runs the check anyway.
• Noticed while reviewing this loop during the [Previous Contributors Response Needed] Transition python-zeroconf to the Apache-2.0 License #1835 audit work; the restructure also retires the last of the 2009-era control flow there.

Test plan

• full compiled test suite (REQUIRE_CYTHON=1 rebuild): 516 passed
• pre-commit clean