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

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 #3869 for these credential types — the client is already fresh before the first 401 occurs
• Proactive recreation should use the same singleflight deduplication as #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 #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

Start in pkg/vmcp/client/client.go at identityPropagatingRoundTripper, then read the linked Phase 1 issue #3869 and RFC THV-0038 for the session-scoped client lifecycle. Done means per-request identity resolution, expiry-aware proactive recreation with singleflight, non-blocking replacement, and the listed unit and integration coverage without unnecessary credential retention.