Integrate unified LLMClient with LiteLLM

[nkanu17]

The current llms.py module has the following pain points:

1. Multiple wrapper classes - Separate OpenAIClientWrapper, AnthropicClientWrapper, and BedrockClientWrapper classes with duplicated logic
2. Manual provider detection - Custom MODEL_NAME_MAP dictionary that needs manual updates for new models
3. Different response parsing for each provider
4. Maintenance burden - Adding new providers requires implementing a new wrapper class and integrating that in the core application code

Solution

Replace the custom wrapper classes with a unified LLMClient abstraction layer backed by LiteLLM, which:

• Supports many LLM providers out of the box
• Handles provider detection automatically from model names
• Normalizes responses across all providers
• Provides built-in model metadata via get_model_info()

The second goal here is also separate application code with LLM logic:

1. Provider API changes are isolated - When OpenAI, Anthropic, or Bedrock update their APIs, LiteLLM handles the burden. We just update the litellm dependency and the rest of the codebase (extraction.py, summarization.py, memory_strategies.py, etc.) remains untouched. Previously, each wrapper class would need individual fixes. Any other fixes can be done.

2. Zero-effort provider expansion - Adding support for new LLM providers requires no application code changes. Examples:

   # Gemini - just use it
   await LLMClient.create_chat_completion(model="gemini/gemini-pro", messages=...)
   
   # Cohere - just use it
   await LLMClient.create_chat_completion(model="command-r-plus", messages=...)
   
   # Local Ollama - just use it
   await LLMClient.create_chat_completion(model="ollama/llama3", messages=..., api_base="http://localhost:11434")

   With the old design, each of these would require a new *ClientWrapper class.

3. Future enhancement/swappability - The abstraction should allow replacing LiteLLM or adding a different library without touching application code.