broker: honor self-imposed ServerKeepAlive in read timeout

[fabracht]

Closes #80.

Summary

When the broker overrides the client's requested keep-alive via BrokerConfig.server_keep_alive (writing ServerKeepAlive into CONNACK per [MQTT-3.2.2-22]), it was continuing to compute its own read-timeout from the client's original requested value rather than the value it just imposed. PR #78 fixed the client side; this is the symmetric broker-side fix.

In build_connack_properties, after writing the ServerKeepAlive property the broker now also updates self.keep_alive, so the downstream read_timeout = self.keep_alive * 1.5 reflects the negotiated value.

A small clamp_keep_alive_to_u16 helper logs a warning if a server_keep_alive > u16::MAX seconds is configured (previously it silently clamped).

Test

broker_read_timeout_uses_negotiated_keep_alive_not_client_request opens a raw TCP socket, sends a hand-crafted CONNECT with keep_alive = 600s against a broker configured with server_keep_alive = 1s, sends no PINGREQs, and asserts the broker drops the connection within ~1.5s (negotiated) rather than ~900s (client request). Verified that reverting just the self.keep_alive update makes this test fail with the expected broker did not close connection within 4s — read_timeout still using client's 600s request message.

Test plan

• cargo test -p mqtt5 --test keepalive_negotiation (all 7 tests pass)
• Counter-example: temporarily reverted the fix and confirmed the new test fails
• cargo make ci-verify clean