v0.5.0

Added

• Backpressure en ingestas grandes (KJR-TSK-0120, roadmap 0.5.0):
  indexDirectory embebe y upsertea por lotes de batchSize
  (DEFAULT_INGEST_BATCH_SIZE = 64) en vez de cargar todos los
  embeddings de un fichero de golpe, con progreso por lote vía onEvent.
  Flag --batch-size N en karajan-rag index con validación estricta.
  Resultado idéntico al indexado sin lotes (mismos chunks y manifest).

• Migración asistida entre stores (KJR-TSK-0119, roadmap 0.5.0):
  scan({batchSize}) como async generator en los tres stores (Pg pagina
  en SQL con orden estable; Lance trocea query().toArray() —
  documentado) y migrateVectorStore(source, target, {batchSize, onProgress}): valida dimensiones antes de escribir, propaga el
  fingerprint vía ensureIndexFingerprint (destino con otro espacio →
  corta sin escribir), upsert por lotes idempotente. Sin re-embedding:
  cambiar de backend (p. ej. LanceDB local → pgvector en cloud) sin
  reindexar.

• Fingerprint persistente en el store (KJR-TSK-0118, roadmap 0.5.0 —
  ADR-002 generalizado): los tres stores exponen
  get/setIndexFingerprint (campo en InMemory, tabla <tabla>_meta en
  Postgres, fichero sidecar .karajan-fingerprint en LanceDB — cópialo
  si mueves la tabla de sitio) y el helper ensureIndexFingerprint
  registra/valida el espacio vectorial fallando con error accionable
  ante mismatch. El indexer easy lo aplica como defensa en profundidad:
  escribir con un embedder/dimensiones incompatibles corta antes de
  mezclar espacios, tenga o no manifest el directorio.

• deleteByDocument(documentId) en los tres vector stores
  (KJR-TSK-0117, roadmap 0.5.0): borra todos los chunks de un documento
  en una llamada. InMemory filtra por metadata.documentId; PgVector por
  metadata->>'documentId'; LanceDB estrena columna top-level
  document_id (las tablas creadas antes de 0.5.0 no la tienen —
  deleteByDocument sobre ellas falla con instrucción de reindexar). El
  indexer easy la usa al invalidar documentos, con fallback al borrado
  por chunkIds del manifest. Queda documentado y testeado que la
  EmbeddingCache (content-addressed: fingerprint + sha256) no requiere
  invalidación ante borrados/reindexados.