Fix worker silent connection drops with idle timeout

[ericflo]

What

Adds a 90-second idle timeout to the worker's WebSocket session loop. If no message is received from the server within that window, the worker assumes the connection is dead and triggers a reconnect.

Why

The worker had no way to detect silently dead connections. When the TCP connection to the proxy dropped without a FIN/RST (common with NAT timeouts, load balancer idle timeouts, or TLS middleboxes), the worker's read loop would block forever — no errors logged, no reconnect attempted. The server's heartbeat mechanism only detects staleness from the server's side; the worker never learned its connection was dead.

This was observed on 2026-04-10: the worker appeared healthy (no errors on CLI) but the proxy returned "Request timed out waiting for worker" to callers. Restarting the worker immediately fixed it.

Changes

• Idle timeout (90s): The server pings every 30s, so 90s (3×) gives margin for transient delays while catching dead connections within ~2 minutes. On timeout, logs a warning and breaks out of the session loop → existing run_with_reconnect handles retry.
• Backoff reset on long sessions: If a session lasted longer than the idle timeout before dropping, it was a genuine connection that eventually died — reset backoff to 1s for fast recovery instead of escalating to 30s.
• Better observability: Added session_duration_secs to all reconnect log messages, and a connected to proxy, registered worker info log on successful connection.

Testing

• All 30 existing tests pass (cargo test -p modelrelay-worker)
• cargo clippy -p modelrelay-worker -- -D warnings clean
• The idle timeout integrates with the existing run_with_reconnect loop — no new reconnect machinery needed