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

This reverts commit abeadc49c8.

Restores vendor/litellm-pgvector/ and the vector_store_registry wiring
(in-band file_search tool-call support) at the user's request, after
re-confirming against docs.litellm.ai/docs/completion/knowledgebase and
litellm-pgvector's own README that pg_vector is still not an in-process
vector_store_registry backend -- it requires this same standalone
connector service either way, so there is no simpler 'native' path that
was missed. Trading back in: 793 lines of vendored code, the untested
Prisma migration, and the git-context build risk noted in VENDORED.md
(all flagged as unverified against real hardware in issue #24), in
exchange for the file_search in-band tool call memory-retrieval did not
support.

Conflicts resolved on top of later commits (Redis, update.sh key-minting
fold-in):
- .env.example / docs/memory-knowledgebase.md: kept the auto-mint-via-
  update.sh language, renamed MEMORY_RETRIEVAL_* back to
  LITELLM_PGVECTOR_*.
- scripts/generate-secrets.sh: left deleted -- its job was folded into
  update.sh in 24d749b, unrelated to this revert.
- scripts/update.sh: renamed the MEMORY_RETRIEVAL_* secret/mint calls to
  LITELLM_PGVECTOR_* to match.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018WHfjWrSEcGhCoeu6dQfDa

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 memory-retrieval
+      # the chat model — see docker-compose.yml. Called by litellm-pgvector
       # to embed knowledgebase content, and available directly at
       # /v1/embeddings for anything else that wants it.
       model: openai/local-embedding
@@ -44,13 +44,21 @@ search_tools:
       search_provider: searxng
       api_base: http://search.home/
 
-# 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.
+# 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
 
 router_settings:
   # ponytail: LiteLLM's request-prioritization scheduler is beta (see