Fixes issue #31 where hash-based deduplication reported finding N groups
but merged 0 memories, causing confusing logs.

**Root Cause:**
- FT.AGGREGATE query was executed as a single string via execute_command()
- This bypassed the FILTER "@count>1" clause, returning all groups including
  unique memories (count=1)
- Processing logic correctly skipped count<=1 groups, resulting in 0 merges

**Solution:**
- Change FT.AGGREGATE execution from single string to individual arguments
- Use execute_command(*agg_query) instead of execute_command(agg_query)
- This ensures the FILTER clause properly excludes unique memories
- Added clearer logging messages

**Testing:**
- All existing tests pass
- Verified fix with integration test showing:
  - 5 memories (2 duplicates + 3 unique) → 4 memories (1 duplicate removed)
  - Proper logging: "Found 1 groups with hash-based duplicates to process"
  - Correctly removes duplicate while preserving unique memories

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <[email protected]>

…tion work

The test was expecting summarization to trigger but the messages were under
the 1000 token limit. Increased the message length to ensure summarization
happens and made the token count assertion more flexible since it varies
based on actual content.

- Replace window_size parameter with model_name in examples and test files
- Rename effective_window_size to effective_token_limit in API for clarity
- Update all references to use the current token-based API instead of
  the old message-count based window_size approach

1. Fix string consistency in FT.AGGREGATE query parameters - now all
   numeric parameters are explicitly converted to strings using str()

2. Handle tool messages and other unknown roles in memory_prompt API -
   treat non-user/assistant roles as assistant messages for MCP compatibility
   since MCP base only supports UserMessage and AssistantMessage types

Fix hash-based deduplication FT.AGGREGATE query execution

- Add openai_api_base and anthropic_api_base fields to Settings
- Update AnthropicClientWrapper to accept and use base_url parameter
- Update get_model_client to use configuration settings instead of env vars directly
- Fix import style to use absolute imports
- Format code with ruff

Co-authored-by: Andrew Brookins <[email protected]>

This prevents both OpenAI and Anthropic client wrappers from being
created when the model is OpenAI, addressing the review comment.

Co-authored-by: Andrew Brookins <[email protected]>

- Add ExtractedMemoryRecord class for explicit memories (defaults to 't')
- Keep MemoryRecord for raw messages (defaults to 'f')
- Update CreateMemoryRecordRequest to use ExtractedMemoryRecord
- Update LenientMemoryRecord to inherit from ExtractedMemoryRecord
- Fix Redis vector store adapter to preserve discrete_memory_extracted field during search
- Update long_term_memory.py type signatures to accept both memory classes

This resolves the issue where MCP-created memories were incorrectly showing
discrete_memory_extracted='f' instead of 't' in search results.

- Add test_mcp_lenient_memory_record_defaults to verify LenientMemoryRecord and ExtractedMemoryRecord default to discrete_memory_extracted='t'
- This ensures regression protection for the memory extraction flag fix

- Add test_redis_adapter_preserves_discrete_memory_extracted_flag to catch the bug where Redis vector store adapter wasn't preserving the discrete_memory_extracted field during search
- Test verifies that memories with discrete_memory_extracted='t' are returned correctly, not defaulted to 'f'
- Includes clear error message to help diagnose similar issues in the future

feat: Make OpenAI and Anthropic API base URLs configurable