fix: HTTP server restart recovery with graceful client reconnection

[zenyr]

Summary

Issue: MCP client panics when HTTP server restarts (same port) because client doesn't reconnect gracefully.

Scenario:

1. MCP HTTP server running
2. MCP client connects, acquires session
3. Server restarts (port unchanged)
4. Client unaware of restart, calls tools/list
5. Server returns 404 (stale sessionId)
6. Expected: Client reconnects gracefully, resumes operation
7. Actual: Client panics (SDK error)

Solution: MCP server cooperatively responds to stale sessions + client handles 404 recovery

Changes

1. Port Conflict Handling (50a9c64)

   • Catch EADDRINUSE on server startup
   • Display helpful error with port and resolution (--port flag or MCP_PTY_PORT env var)

2. Session Init Race Condition (9070546)

   • Explicit wait loop (100ms) when concurrent requests initialize session
   • Prevents 'Server not initialized' 500 errors
   • Timeout reduced from 5s → 100ms (microseconds in practice)

3. 404 Recovery (Stale Session) (2109330)

   • Remove deferred init on 404 to prevent race condition
   • Server immediately ready when issuing new sessionId
   • Client receives 404 + new sessionId header, SDK auto-updates

Tests

• ✅ 8/8 HTTP transport tests passing
• ✅ E2E recovery flow validates stale session → 404 → new session → operational
• ⚠️ E2E test has incorrect assumptions (see comments)

[zenyr]

E2E Test Issue: Incorrect Assumptions

Problem: Current E2E test doesn't validate actual recovery scenario. Test maintains single client instance throughout, but recovery requires graceful reconnection.

Current Test Behavior:

// Phase 2-3: Kill + restart server
await killSrv();        // Manually deletes sessionManager sessions
await startSrv(6426);   // Restart server

// Phase 4: Client calls with stale sessionId
await call("2");        // Logs 404 but doesn't validate graceful reconnection
state.s2 = tr.sessionId;  // Just records new sessionId after 404

Why This is Wrong:

1. Manual sessionManager.deleteSession() is fake server restart (not actual)
2. Client instance never breaks connection/reconnects — it just keeps existing connection
3. 404 recovery assumed, but not validated that client remains functional
4. Real scenario: client should survive server restart, not just absorb new sessionId

Expected Behavior (per scenario):

• Server restarts → old sessionId invalid → 404
• Client receives 404 + new sessionId header
• SDK auto-updates transport.sessionId
• Client continues to work with new session (no panic, no errors)

Test Should Validate:

1. Client instance persistent throughout test (no teardown/reconnect)
2. Before restart: normal operation ✅
3. After restart: tools/list etc. returns 404 on first call ✅
4. SDK gracefully updates sessionId (SDK responsibility, test assumption ok)
5. After recovery: client calls succeed again ✅
6. Critical: Zero "Server not initialized" or panic errors from client

Correct Test Pattern:

• Keep client instance alive across server kill/restart
• Validate first call post-restart yields 404 (stale session)
• Validate subsequent calls succeed (client auto-updated sessionId)
• Timeout/error handling for client retries is SDK responsibility

Action: Next commit should fix test to validate above pattern + add assertions for graceful reconnection.