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

scripts/ingest-memory.sh

@@ -1,37 +1,48 @@
 #!/usr/bin/env bash
-# Loads data/memory.md and data/claude-legacy-memory.md into the
-# memory-retrieval knowledgebase (POST /ingest).
+# Loads data/memory.md and data/claude-legacy-memory.md into the LiteLLM
+# knowledgebase (the "memory-and-notes" vector store, see litellm-config.yaml)
+# via litellm-pgvector's batch-embeddings endpoint.
 #
 # ponytail: one chunk per non-empty, non-heading line — both source files are
 # already one fact/paragraph per line (no hard-wrapping), so this needs no
-# real chunking logic. Re-run after editing either file; there's no dedup,
-# PGVector always inserts — clear the collection first if you need a clean
+# real chunking logic. Re-run after editing either file; there's no dedup, so
+# this appends duplicates on a second run against unchanged content — clear
+# the store first (DELETE the vector_store_id's rows) if you need a clean
 # reload.
 set -euo pipefail
 cd "$(dirname "$0")/.."
 
 [ -f .env ] && set -a && . ./.env && set +a
 
-: "${MEMORY_RETRIEVAL_API_KEY:?Set MEMORY_RETRIEVAL_API_KEY in .env first}"
-MEMORY_RETRIEVAL_URL="${MEMORY_RETRIEVAL_URL:-http://localhost:8000}"
+: "${LITELLM_PGVECTOR_API_KEY:?Set LITELLM_PGVECTOR_API_KEY in .env first}"
+LITELLM_PGVECTOR_URL="${LITELLM_PGVECTOR_URL:-http://localhost:8000}"
+VECTOR_STORE_ID="memory-and-notes"
+
+# Must match litellm-config.yaml's vector_store_registry entry — the
+# registry just points at a store the backend must already know about.
+# Ignores failure if it already exists (no documented idempotency check).
+curl -sf -X POST "${LITELLM_PGVECTOR_URL}/v1/vector_stores" \
+  -H "Authorization: Bearer ${LITELLM_PGVECTOR_API_KEY}" \
+  -H "Content-Type: application/json" \
+  -d "{\"name\": \"${VECTOR_STORE_ID}\"}" > /dev/null 2>&1 || true
 
 ingest_file() {
   local file="$1" section=""
-  local chunks="[]"
+  local batch="[]"
   while IFS= read -r line; do
     case "$line" in
       "#"*) section="${line#\# }"; section="${section#\#\# }"; continue ;;
       ""|"---") continue ;;
     esac
-    chunks=$(jq --arg content "$line" --arg source "$file" --arg section "$section" \
-      '. += [{"content": $content, "metadata": {"source": $source, "section": $section}}]' <<<"$chunks")
+    batch=$(jq --arg content "$line" --arg source "$file" --arg section "$section" \
+      '. += [{"content": $content, "metadata": {"source": $source, "section": $section}}]' <<<"$batch")
   done < "$file"
 
-  echo "Ingesting $(jq 'length' <<<"$chunks") chunks from $file..."
-  curl -sf -X POST "${MEMORY_RETRIEVAL_URL}/ingest" \
-    -H "Authorization: Bearer ${MEMORY_RETRIEVAL_API_KEY}" \
+  echo "Ingesting $(jq 'length' <<<"$batch") chunks from $file..."
+  curl -sf -X POST "${LITELLM_PGVECTOR_URL}/v1/vector_stores/${VECTOR_STORE_ID}/embeddings/batch" \
+    -H "Authorization: Bearer ${LITELLM_PGVECTOR_API_KEY}" \
     -H "Content-Type: application/json" \
-    -d "{\"chunks\": ${chunks}}" > /dev/null
+    -d "$batch" > /dev/null
 }
 
 ingest_file data/memory.md

scripts/update.sh

@@ -39,7 +39,7 @@ set_if_blank LITELLM_DB_PASSWORD "$(openssl rand -hex 32)"
 set_if_blank REDIS_PASSWORD "$(openssl rand -hex 32)"
 set_if_blank UI_PASSWORD "$(openssl rand -hex 16)"
 set_if_blank PGVECTOR_DB_PASSWORD "$(openssl rand -hex 32)"
-set_if_blank MEMORY_RETRIEVAL_API_KEY "$(openssl rand -hex 32)"
+set_if_blank LITELLM_PGVECTOR_API_KEY "$(openssl rand -hex 32)"
 
 echo "==> resolving SEARXNG_LAN_IP"
 # search.home is a LAN mDNS/local-DNS name — resolvable from this host, just
@@ -66,7 +66,7 @@ docker compose build --pull
 echo "==> bringing up litellm (needed to mint virtual keys below)"
 docker compose up -d --wait litellm-db litellm
 
-# OPENWEBUI_LITELLM_KEY / MEMORY_RETRIEVAL_EMBEDDING_KEY are per-workload
+# OPENWEBUI_LITELLM_KEY / LITELLM_PGVECTOR_EMBEDDING_KEY are per-workload
 # virtual keys, not random secrets — minted via LiteLLM's own API
 # (docs/proxy-key-onboarding.md documents the manual Admin UI route; this is
 # the same thing over the REST endpoint LITELLM_MASTER_KEY already
@@ -96,7 +96,7 @@ mint_key_if_blank() {
   fi
 }
 mint_key_if_blank OPENWEBUI_LITELLM_KEY openwebui
-mint_key_if_blank MEMORY_RETRIEVAL_EMBEDDING_KEY memory-retrieval
+mint_key_if_blank LITELLM_PGVECTOR_EMBEDDING_KEY litellm-pgvector
 set -a && . ./.env && set +a
 
 echo "==> recreating changed services"