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

[yrobla]

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

[yrobla]

Implementation note from Phase 1 (PR #3882)

The admission-control abstraction introduced in Phase 1 (AdmissionQueue in pkg/vmcp/session/admission.go) is directly applicable here.

The invariant that makes reinitializeBackend tricky is the same one AdmissionQueue solves: you cannot hold a write-lock while performing network I/O (connecting to a backend), yet you need to prevent new requests from reaching a backend that is mid-reinitialisation.

Suggested approach for Phase 2:

• Each backend entry in the connections map gets its own AdmissionQueue.
• To reinitialise: call queue.CloseAndDrain() on the old entry (blocks until in-flight calls complete, prevents new ones), create a new connection, then swap in a fresh AdmissionQueue alongside it.
• This avoids holding a write-lock during the connection handshake entirely.

cc @jerm-dro