Run first host health check immediately and apply health state on registration + fix CI by upgrading CMake version

[Rahmeen14]

Summary

The HostHealthMonitor previously waited a full pollInterval before its first health check and didn't remember the health state, so consumers could start consuming before the host was verified, and a connection registering while the host was unhealthy would wait until the next poll to pause. This makes the first check immediate, caches the state and applies it on registration, and improves the health logging.

Changes

• Immediate first check — start() arms the timer with a zero delay, so the first check fires on the event loop right away instead of after a full pollInterval; checkHealth() reschedules subsequent checks at pollInterval.
• Cached health + fail-safe default — the monitor caches the last known health, defaulting to UNHEALTHY until the first check completes, so consumers don't consume from an unverified host.
• Apply health on registration (symmetric) — registerConnection brings a connection into the current known state immediately: resumed if the host is known healthy (consumers start active without waiting for the next poll), paused if unhealthy. Each subsequent poll re-applies the latest state to every registered connection, so a consumer created at any point opens in the current known state.
• Health-transition logging — host health transitions (healthy↔unhealthy) log at INFO (event=health-state-changed …); per-check outcomes are DEBUG to avoid steady-state noise. Health log lines use field=value format for aggregation.
• Tests — cover the immediate first check and the register-while-healthy / register-while-unhealthy / register-before-first-check paths.
• Also fixes broken CI - Debian stable ships CMake 3.31, but current vcpkg port scripts call string(JSON..STRING_ENCODE), which was added in CMake 4.3. Install a modern CMake from PyPI (arch-independent) so vcpkg dependency builds succeed.

[flamble]

I noticed a docs discrepancy when checking the docs on this call.

The (existing) docs for reset say "It is invalid to call reset without calling start first." which we're not doing with this d_timer.

However, it's created with createWithCallback , which says "The timer should be started by calling reset()."

We should address this discrepancy in a future PR.