feat(schema): esquema declarativo + seed v3 del formulario [4B]

Extiende questions con instance_generator/instance_of/hint.
Instrumento v3 completo (10 secciones, 50 preguntas) como datos declarativos.
Operadores de flujo para multiple_choice: contains, eq_sole.
Flujo del formulario en el esquema, no en presentación (ADR-005).
Seed solo reemplaza catálogo; no toca evidencia de consentimiento (ADR-003).

sprints/sprint-4/PASO_0_PRESERVACION.md

@@ -0,0 +1,95 @@
+# PASO 0 — Preservación de v2.1.0 antes de arrancar Sprint 4
+
+> Ejecutar ANTES de tocar nada de v3. Estos pasos preservan el estado actual
+> estable como punto de retorno seguro.
+
+---
+
+## Objetivo
+1. Crear tag `v2.1.0` sobre el commit actual de `main`.
+2. Crear rama `v2.1.0-stable` que preserva el código de v2.
+3. Generar un dump de la base de datos de producción y versionarlo en esa rama.
+4. Crear `CHANGELOG.md` en `main`.
+5. Dejar `main` listo para desarrollo de v3.
+
+---
+
+## Secuencia de comandos
+
+### 1. Asegurarse de estar en main actualizado
+```bash
+git checkout main
+git pull origin main
+git status   # debe estar limpio
+```
+
+### 2. Crear el tag de la versión estable actual
+```bash
+git tag -a v2.1.0 -m "Versión 2.1.0 — formulario lineal, dashboard multitenante, instrumento v2.1"
+git push origin v2.1.0
+```
+
+### 3. Crear la rama de preservación
+```bash
+git checkout -b v2.1.0-stable
+git push -u origin v2.1.0-stable
+```
+
+### 4. Generar el dump de la base de datos (en el VPS)
+```bash
+# En el VPS inq-mart-2:
+docker exec supabase-db pg_dump -U postgres --clean --if-exists postgres \
+  | gzip > ~/dump_v2.1.0_$(date +%Y%m%d).sql.gz
+
+# Verificar tamaño
+ls -lh ~/dump_v2.1.0_*.sql.gz
+```
+
+### 5. Traer el dump a la máquina local y agregarlo a la rama
+```bash
+# En tu Mac, desde el repo, estando en la rama v2.1.0-stable:
+mkdir -p db-snapshots
+scp administrator@172.20.5.11:~/dump_v2.1.0_*.sql.gz db-snapshots/
+
+git add db-snapshots/
+git commit -m "chore(v2.1.0): snapshot de base de datos de producción
+
+Dump completo de la DB de producción al momento del corte v2.1.0.
+Incluye: 3 organizaciones, 3 surveys, 132 questions, 15 responses, ~500 answers.
+Preservado antes de iniciar el desarrollo de v3 (wizard)."
+git push origin v2.1.0-stable
+```
+
+### 6. Volver a main y crear el CHANGELOG
+```bash
+git checkout main
+# Crear CHANGELOG.md (contenido en el archivo adjunto)
+git add CHANGELOG.md
+git commit -m "docs: agregar CHANGELOG con versionado semántico
+
+Establece la convención SemVer para el proyecto.
+v2.1.0 documentada como versión estable actual.
+v3.0.0 (wizard) marcada como en desarrollo."
+git push origin main
+```
+
+---
+
+## Verificación final
+```bash
+git tag -l              # debe mostrar v2.1.0
+git branch -a           # debe mostrar main y v2.1.0-stable
+git log --oneline -3    # en main, último commit es el CHANGELOG
+```
+
+A partir de acá, todo el trabajo de v3 va en `main`. La rama `v2.1.0-stable`
+queda congelada como referencia y punto de retorno.
+
+---
+
+## Nota sobre el dump
+El dump en `db-snapshots/` permite recrear la DB de v2.1.0 si fuera necesario
+volver atrás. Para restaurarlo:
+```bash
+gunzip -c dump_v2.1.0_YYYYMMDD.sql.gz | docker exec -i supabase-db psql -U postgres -d postgres
+```