[vMCP] Handle backend session expiration with automatic re-initialization

Depends on #3865

When a backend returns a session-expired error (HTTP 404 or "session not found"), the vMCP session should automatically re-initialize the backend client and retry the operation once, preserving the vMCP session from the client's perspective.

Implementation:

• Detect isSessionExpiredError(err) after the initial call
• reinitializeBackend: acquire write lock, close old client, create new client (triggers new InitializeRequest handshake), update client map and backend session ID map
• Re-read the updated client under RLock after re-initialization
• Retry the operation exactly once; if it fails again, return the error immediately
• Use singleflight to deduplicate concurrent expiration detections for the same backend

Acceptance Criteria

• A backend session-expired error triggers automatic re-initialization of that backend client
• The operation is retried exactly once with the new client
• A second consecutive failure is returned to the caller immediately (no further retries)
• Both the initial and post-reinit reads from the client map are protected by RLock
• reinitializeBackend holds the write lock while replacing the client
• Concurrent expiration detections for the same backend result in only one re-initialization (via singleflight)
• The vMCP session is unaffected by backend session expiration from the client's perspective
• Unit tests cover: successful retry, double failure, concurrent detections deduplicated

RFC: THV-0038 — Session-scoped client lifecycle

Start by locating the vMCP backend operation path, the client map and backend session ID map, and the existing isSessionExpiredError handling. Trace how reinitializeBackend should acquire locks and use singleflight, then add unit coverage for successful retry, double failure, and concurrent deduplication. Done means one re-initialization and one retry preserve the vMCP session, while a second failure returns immediately.