refactor: compute service info request pacing from fresh clock reads - #1895

Summary

Restructures the ServiceInfo.async_request polling loop the same way #1888 restructured the registration probe loop: wait-first if/continue shape, a fresh clock read at the top of each cycle, and deadline arithmetic in place of the carried now/next_/last trio. This is the last structural item from the tenth audit's inventory (#1835).

Details

• Behavior preserved: fail at the deadline or on denial; the first query goes out immediately (QU unless a question type is passed, later queries QM); each send schedules the next at delay plus random jitter; the QM duplicate question escalation stands; every wake from a record update re-checks completeness; the listener is always removed.
• Wait durations are computed from the current clock rather than a value cached before the previous send, so queries land on schedule instead of accumulating per-cycle lag.
• The loop now reads the same way as async_check_service without being coupled to it. A shared pacing primitive was considered and rejected: the two loops differ in termination (probe count vs deadline/completion), cadence (fixed schedule vs adaptive jitter) and wake condition (engine notify vs the info's own futures), so extraction would be a callback-shaped abstraction bigger than the three lines it saves, with bound-method indirection in a Cythonized module.
• Perf: one extra current_time_millis() call per query sent, in a loop whose iterations are separated by 25 to 1000 ms waits; no per-packet or per-record path changed and nothing in info.pxd is touched.

Test plan

• full compiled test suite after REQUIRE_CYTHON=1 rebuild: 518 passed
• pre-commit clean
• four-agent simplify review: reuse, efficiency and altitude clean; the flatter loop shape it proposed was declined since it is the 2009 statement sequence this change retires