fix: clear socketTimeout timer on close so it can't destroy the reconnected socket - #62

Problem

When socketTimeout is set, the timer armed by setSocketTimeout() is only ever
cleared inside its own stream.once("data") handler. If the socket the timer was
armed for closes before any reply arrives (e.g. the connection drops with a
command in flight), that "data" handler never fires, so the timer is never cleared.

The timer callback runs this.stream.destroy(...) — and by the time it fires,
this.stream points to the new socket created by the reconnect. So a healthy,
freshly-reconnected socket is destroyed with a spurious
Socket timeout. Expecting data... error, triggering yet another reconnect.

There's a second effect: because a new timer is only armed when
socketTimeoutTimer === undefined, the stale timer also prevents the reconnected
socket from being monitored until it fires.

Reproduction (socketTimeout: 1000): send a command, drop the socket before any
reply, let the client reconnect — ~1000ms after the original command the stale timer
fires and destroys the healthy socket.

Fix

Add Redis#clearSocketTimeout() and call it from closeHandler, which runs on every
socket close (wired via stream.once("close", ...)) before any reconnect. This cancels
the stale timer so the next command re-arms a fresh one on the current socket.

Tests

Added a functional regression test that arms the timer, drops the socket to force a
reconnect, and asserts the healthy reconnected socket is not destroyed. Verified it
fails on main and passes with this fix. Existing socketTimeout tests still pass.