feat(knowledgebase): replace litellm-pgvector connector with memory-retrieval

Per docs/research/langchain-pgvector-vs-litellm-pgvector.md (issue #25):
the vendored litellm-pgvector connector (793 lines, Prisma migrations, a
fragile git-context build) is replaced by a ~90-line FastAPI service
(services/memory-retrieval/) wrapping langchain_postgres.PGVector directly
against pgvector-db. Same gateway boundary — it still calls litellm for
embeddings, nothing talks to Postgres or the model directly except this
service.

- New services/memory-retrieval/ (main.py, Dockerfile, requirements.txt):
  POST /ingest, POST /query, GET /health.
- docker-compose.yml: litellm-pgvector service replaced by memory-retrieval;
  pgvector-db and embedding-server untouched.
- litellm-config.yaml: vector_store_registry block removed (no
  langchain_postgres provider exists to register against; callers query
  memory-retrieval directly instead of an in-band file_search tool call —
  that mechanism was never confirmed working per issue #24 anyway).
- scripts/ingest-memory.sh rewritten for the new /ingest endpoint (same
  per-line chunking, no dedup).
- .env vars renamed: LITELLM_PGVECTOR_API_KEY/LITELLM_PGVECTOR_EMBEDDING_KEY
  -> MEMORY_RETRIEVAL_API_KEY/MEMORY_RETRIEVAL_EMBEDDING_KEY.
- vendor/litellm-pgvector/ removed entirely.
- docs/memory-knowledgebase.md updated for the new setup/query flow.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

litellm-config.yaml

@@ -25,7 +25,7 @@ model_list:
   - model_name: local-embedding
     litellm_params:
       # Served by the dedicated embedding-server (nomic-embed-text-v1.5), not
-      # the chat model — see docker-compose.yml. Called by litellm-pgvector
+      # the chat model — see docker-compose.yml. Called by memory-retrieval
       # to embed knowledgebase content, and available directly at
       # /v1/embeddings for anything else that wants it.
       model: openai/local-embedding
@@ -44,21 +44,13 @@ search_tools:
       search_provider: searxng
       api_base: http://search.home/
 
-# Knowledgebase / RAG, backed by the litellm-pgvector companion service (NOT
-# Qdrant — LiteLLM's native vector-store feature has no Qdrant provider, see
-# docs/research/litellm-knowledgebase.md). vector_store_id is this proxy's
-# own identifier for the store, not assigned by a backend.
-# ponytail: field names here (custom_llm_provider: pg_vector, api_base
-# pointed at litellm-pgvector) are the best fit from the litellm-pgvector
-# README, not confirmed against a running deploy yet — smoke-test before
-# relying on it. See issue #24.
-vector_store_registry:
-  - vector_store_name: memory-and-notes
-    litellm_params:
-      vector_store_id: "memory-and-notes"
-      custom_llm_provider: pg_vector
-      api_base: http://litellm-pgvector:8000
-      embedding_model: local-embedding
+# Knowledgebase / RAG lives outside LiteLLM's own registry now — see the
+# memory-retrieval service (docker-compose.yml) and
+# docs/research/langchain-pgvector-vs-litellm-pgvector.md. LiteLLM's native
+# vector_store_registry has no Qdrant provider and no langchain_postgres
+# provider either, so registering a store here isn't an option; callers
+# query memory-retrieval's /query endpoint directly instead of an in-band
+# file_search tool call.
 
 router_settings:
   # ponytail: LiteLLM's request-prioritization scheduler is beta (see