[vMCP] Proactive auth credential refresh via per-request identity resolution (Phase 2)

[yrobla]

Depends on #3869

This is the Phase 2 follow-up to #3869 (auth credential expiration with retry). Phase 1 handles stale credentials reactively (detect 401/403, recreate client). This issue eliminates the problem proactively by resolving credentials on every operation rather than at client creation time.

Context: With session-scoped clients, outgoing credentials are resolved once during SessionFactory.MakeSession() and held for the session lifetime. Short-lived credentials (OAuth tokens, expiring API keys) can become stale mid-session, triggering the retry path in #3869. This issue removes that failure mode entirely for credentials with a known expiry.

Implementation:

Part 1 — Per-request identity resolution:

• Modify identityPropagatingRoundTripper in pkg/vmcp/client/client.go to read identity from the request context on each operation, instead of capturing it at client creation time
• This ensures every backend call automatically picks up the latest credentials without any expiry tracking logic
• Eliminates stale credential issues entirely for backends that return fresh credentials on each resolution

Part 2 — Proactive client recreation for known-expiry credentials:

• For credentials that carry an explicit expiry (JWT exp claim, OAuth expires_in response field), schedule proactive client recreation shortly before the expiry time
• This avoids the reactive retry path in [vMCP] Handle auth credential expiration with retry and proactive refresh #3869 for these credential types — the client is already fresh before the first 401 occurs
• Proactive recreation should use the same singleflight deduplication as [vMCP] Handle auth credential expiration with retry and proactive refresh #3869 to handle concurrent requests during the recreation window

Acceptance Criteria

• identityPropagatingRoundTripper resolves identity from the request context on each operation rather than capturing it at construction time
• Backends that return fresh credentials on each resolution never trigger the reactive retry path from [vMCP] Handle auth credential expiration with retry and proactive refresh #3869
• For credentials with a known expiry (exp claim or expires_in), proactive recreation is scheduled before the expiry time
• Proactive recreation uses singleflight to deduplicate concurrent requests during the recreation window
• Proactive recreation does not block in-flight requests — existing clients remain usable until replaced
• No credentials are logged or stored beyond what is required for the current request
• Unit tests cover: per-request identity resolution picks up updated credentials, proactive recreation fires before expiry, concurrent requests during recreation window are deduplicated
• Integration tests cover: full request lifecycle with short-lived credentials, no 401s observed when proactive refresh is working correctly

---

RFC: THV-0038 — Session-scoped client lifecycle

[yrobla]

Scope clarification from Phase 1 (PR #3882)

The fix for per-request identity propagation should be scoped to the old client path only (pkg/vmcp/client/client.go → identityPropagatingRoundTripper).

Phase 1 introduced a new identityRoundTripper in pkg/vmcp/session/internal/backend/ which intentionally captures identity at session-creation time rather than per-request. This is correct behaviour for that code path: in the new session-scoped model, the identity is fixed for the lifetime of the session (established during the initial client handshake) and does not change between calls.

Summary of what to fix vs. what to leave alone:

• ✅ Fix pkg/vmcp/client/client.go identityPropagatingRoundTripper to read identity from the per-request context.
• ✅ Leave pkg/vmcp/session/internal/backend/identityRoundTripper as-is — session-scoped identity capture is the intended design.

cc @jerm-dro