chore(ops): backup y restore de la base PostgreSQL productiva

[MrDylanDev]

Closes #60

Summary

• Estrategia de backup/restore para la base PostgreSQL productiva: servicio backup con cron en el stack prod (pg_dump diario 02:00 a directorio del host, retención configurable).
• Scripts reutilizables backup.sh (escritura atómica + verificación gzip -t + retención) y restore.sh (psql ON_ERROR_STOP=1, base fresca).
• Documentación operativa con RPO (24 h) / RTO (< 30 min), restore paso a paso y hardening recomendado.
• Job de CI que prueba el ciclo completo backup → restore → verificación de datos → retención, contra Postgres 16 real.

Changes

File	Change
docker-compose.prod.yml	Agrega servicio backup (cron, bind mount ./backups, healthcheck)
scripts/backup.sh	pg_dump | gzip con validación y retención (BACKUP_RETENTION_DAYS)
scripts/restore.sh	Restore desde dump .sql.gz con ON_ERROR_STOP
docs/ops/backup-restore.md	Estrategia, RPO/RTO, restore paso a paso, hardening
.env.prod.example	Vars BACKUP_SCHEDULE, BACKUP_RETENTION_DAYS, BACKUP_HOST_DIR
.github/workflows/ci.yml	Job backup-restore (ciclo completo contra Postgres real)
.gitignore	Ignora backups/

Test Plan

• Validado el ciclo completo localmente con Docker: backup → restore → 1 fila verificada → retención (dump de 8 días eliminado) → fallo con base caída no deja dumps corruptos
• bash -n scripts/backup.sh scripts/restore.sh sin errores
• docker compose -f docker-compose.prod.yml config válido (escapado $$ correcto)
• Job backup-restore del CI ejecuta el mismo ciclo en cada PR

Checklist

• Issue aprobado vinculado (status:approved)
• Label type:chore
• Conventional commit
• Sin Co-Authored-By