feat: add TTL/LRU eviction to ConnectionManager per-URL InstanceState map to bound memory in high-cardinality multi-instance scenarios

[coderabbitai]

Summary

In src/services/ConnectionManager.ts, the instances: Map<string, InstanceState> retains a GraphQLClient, SchemaIntrospector, version/schema data, and scope info for every normalized URL added during the process lifetime. Successful entries are only reclaimed by reinitialize() or reset(). In multi-instance OAuth traffic with many tenants, this means memory grows unboundedly.

In practice, MCP servers typically handle 1–3 instances (default + OAuth-switched), so the impact is low for the common case. However, a TTL/LRU eviction mechanism would make the implementation safe for high-cardinality deployments.

Proposed Work

• Add a removeInstance(url: string) method that:
  • Removes the entry from instances, initializePromises, and introspectionPromises
  • Clears the matching entry from the static introspectionCache (and related CacheEntry)
  • Tears down any GraphQLClient/SchemaIntrospector resources if they require explicit cleanup
• Add an LRU eviction policy (e.g., max N entries) and/or a TTL-based prune routine (using CACHE_TTL as a hint) to automatically drop stale entries
• Wire session/registry cleanup paths to call removeInstance(normalizedUrl) when a session or tenant is torn down
• Consider a periodic evictExpiredInstances() routine callable by HealthMonitor or a scheduler

Context

• Raised in PR feat: add connection resilience with XState health monitor #369 review: feat: add connection resilience with XState health monitor #369 (comment)
• Deferred from PR feat: add connection resilience with XState health monitor #369 as an out-of-scope architectural change
• Requested by @polaz