fix(stratum_v1): bound pool reads by length and idle time

[Schnitzel]

Problem

Two related robustness gaps in the stratum client, both reachable by a malicious pool or a MITM (the transport is plaintext):

1. Unbounded read buffer — Connection::read_message loops BufReader::read_line into a growable String with no length cap. A peer that never sends \n grows the daemon's memory until the OOM killer ends it (≈1 GB per 25 s at 100 Mbps, or arbitrarily slowly via a drip).
2. No idle timeout — the main event loop awaits pool messages with no timeout. A dead or deliberately silent connection leaves the miner neither working nor reconnecting; TCP keepalive takes hours to notice.

Found during a source review of the pool-facing input handling.

Fix

• Cap messages at 64 KiB (MAX_MESSAGE_LEN): the read goes through a length-limited adapter, and a line that fills the cap without a terminating newline is rejected with a new StratumError::MessageTooLarge. 64 KiB is ~10× the largest legitimate message (mining.notify with a big coinbase and many merkle branches). The error terminates the connection; the source reconnects with the usual jittered backoff.
• 20-minute idle timeout (POOL_IDLE_TIMEOUT) around pool reads in the client main loop. Pools send mining.notify at least as often as new blocks arrive (10 min average), so 20 minutes of silence means the connection is dead; a timeout errors the connection and triggers the normal reconnect path.

Neither change affects the handshake/submit paths, which already have 30 s request timeouts.

Tests

• test_oversized_message_rejected: an unterminated 64 KiB+1 line is rejected with MessageTooLarge.
• test_max_length_message_accepted: a well-formed message just under the cap still parses.
• test_silent_pool_recycles_connection: paused-time test; after a mock handshake the pool says nothing and the client exits with Timeout, i.e. the caller reconnects.

cargo fmt, cargo clippy (no new warnings), and cargo test (355 passed) are green; each commit passes on its own.