[jakobzach]

Description

Follow-up to #3499 and the ChatGPT/Codex finding.

If a reconnecting callback destroys the client or closes it with an empty queue, the socket currently starts another connection after the callback returns. That attempt captures the already-incremented teardown epoch and can revive the closed client.

Snapshot the teardown epoch before emitting reconnecting and stop if the callback changed it. Graceful close() with queued commands still connects and drains normally.

@nkaradzhov this uses the small post-callback check proposed in the previous review thread. The production change is two lines.

Validation

• Both new public-client regressions (destroy() and empty-queue close() inside reconnecting) fail on unmodified upstream 1fd0e5f83a and pass with the fix.
• Extended the existing queued-close regression to run inside the callback and preserve draining.
• 30 focused socket/close tests, build, client type tests and changed-file lint pass.
• Full npm test was attempted on Node 22.23.2 with Docker Desktop. Stopped after three container-readiness hooks timed out: Redis answered PING inside its container, but host connections to the test port were refused on both IPv4 and IPv6. The harness uses --network host; full-suite validation remains blocked by local Docker networking.
• The focused run excludes Docker-backed tests and the existing retry-counter test.

Checklist

• Does npm test pass with this change (including linting)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)? (No public API change.)

[nkaradzhov]

@jakobzach thanks, somehow i missed the previous comment. LGTM

[nkaradzhov]

Should we merge this?