[T23] Dockerización — bot + Chroma + scheduler

[johnma96]

Objetivo

El proyecto entero corre con docker compose up, sin depender de la máquina
local.

Contexto

Prerequisito de V4 (despliegue en Cloud Run). Y resuelve el hack de pysqlite3
que hoy está duplicado al inicio de tres scripts: en un contenedor con la versión
correcta de sqlite3, el hack desaparece.

Criterios de aceptación

• Dockerfile multi-stage: etapa de build con uv, etapa runtime mínima
• Imagen final sin herramientas de build ni caché de uv
• docker-compose.yml con los servicios necesarios según la decisión de T21
  (uno o dos procesos)
• Chroma con persistencia en volumen — los datos sobreviven a
  docker compose down
• Secretos por variables de entorno, nunca en la imagen; .env en
  .dockerignore
• docker compose up levanta todo y el bot responde desde el teléfono
• Verificado si el hack de pysqlite3 se puede eliminar dentro del
  contenedor; si sí, eliminarlo de los scripts
• README con la sección de cómo correr con Docker

Capas afectadas

• Dockerfile, docker-compose.yml, .dockerignore — nuevos
• scripts/*.py — posible eliminación del hack de pysqlite3
• README.md

Decisiones a documentar

Modelo de embeddings dentro de la imagen. sentence-transformers descarga
el modelo en el primer uso. Incluirlo en la imagen la infla decenas de megas
pero evita descargas en cada arranque de contenedor. Decidir.

Chroma embebido o como servicio. Hoy es PersistentClient local. En
compose podría seguir embebido en el proceso del bot (más simple) o correr como
servicio separado (necesario si el scheduler también escribe). Depende de T21.

Objetivo de aprendizaje

Multi-stage builds y por qué importan para el tamaño de imagen. Gestión de
estado persistente en contenedores. Por qué los secretos no van en la imagen.

Fuera de alcance

Cloud Run, CI/CD, Kubernetes. Todo V4 o V6.

Estimación

5h

Depende de

T21 y T22 — el compose refleja la arquitectura de procesos que resulte de ambos.