Add timeouts and bounded reconnect to Redis client

[masnwilliams]

Summary

The Redis client retried reconnecting forever with no connect or command timeout. When Redis was unreachable, any command (e.g. the OAuth org-context writes in /token) blocked until the serverless function limit instead of throwing — so kernel login hung after the browser showed "authentication successful" rather than failing with an error.

This bounds the failure:

• Bounded reconnect — reconnectStrategy now returns an Error after MAX_RECONNECT_ATTEMPTS (10) instead of retrying indefinitely, so queued commands reject when Redis stays down.
• Connect timeout — connectTimeout (5s) on the socket so a black-holed connection fails fast.
• Per-command timeout — every op runs through withTimeout (5s ceiling) so a stalled-but-connected command surfaces as an error.

Net effect: a Redis outage returns a clean error in seconds instead of hanging the caller.

Test plan

• tsc --noEmit passes
• prettier clean
• Manual: confirm normal OAuth login still succeeds against a healthy Redis (behavior unchanged on the happy path)

Follow-up companion PR on kernel/cli adds a timeout on the CLI token exchange so it also fails fast.

---

Note

Medium Risk
Touches all Redis-backed org-context paths used during token exchange; mis-tuned timeouts could cause false failures under slow Redis, though happy-path behavior should stay the same.

Overview
Redis failures now surface in seconds instead of hanging OAuth/token handlers (e.g. /token org-context writes and kernel login after the browser succeeds).

The shared redis client adds a 5s per-command ceiling via withTimeout, 3s socket connectTimeout, and a reconnect strategy that stops after two connect attempts (returns an error instead of retrying forever). Connection handling drops the manual isConnected / event listeners in favor of client.isReady, shares one in-flight connect() via openConnection, and introduces resetClient() (destroy() on a stuck open socket) so failed connects, command timeouts, and transient socket errors can retry on a clean client instead of hitting “Socket already opened.”

^{Reviewed by Cursor Bugbot for commit 1ff018b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
mcp	Ready	Preview, Comment	Jul 20, 2026 6:59pm

[vercel]

Additional Suggestion:

The 5s command timeout does not cover ensureConnected()/client.connect(), so an unreachable Redis blocks the caller for ~60s+ instead of the intended ~5s budget.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 29d6903. Configure here.}