fix(health): bound active HTTP connections

[ValarDragon]

Summary

• cap the health server at 100 simultaneous TCP connections
• expire incomplete or slow health requests after 10 seconds
• disable HTTP keep-alive so each accepted connection serves one probe
• cover idle-client and connection-saturation behavior with regression tests

Root cause

The health listener accepted connections based only on a per-interval counter.
Each accepted socket spawned a detached Hyper task with no active-connection
limit or request timeout, so clients could keep accepted sockets open while the
counter reset and later connections created additional tasks.

Fix

The accept loop now acquires an owned semaphore permit before spawning a
connection task. Connections beyond the active limit are dropped immediately,
and the permit is held until Hyper finishes or the connection-wide request
timeout expires. HTTP/1 keep-alive is disabled because the health API only
serves lightweight probe requests.

The existing accept-rate counter remains as a burst limit, with its interval
reset applied before the next connection is counted.

Validation

• cargo test -p zakura components::health
• cargo fmt --all -- --check
• cargo clippy -p zakura --lib -- -D warnings

The targeted suite includes new tests proving that idle sockets are closed and
that connections above the active limit cannot receive a health response.

[v12-auditor]

Note

Complete: Audit complete. No review-worthy issues remain after automatic triage. Two findings were auto-invalidated.

Open the full results here.

Analyzed two files, diff 18dbc60...e9a4512.