[Relay][P1] Añadir jobs de retención para estado efímero y auditoría

[0bkevin]

Contexto auditado

T3 Connect ejecuta mantenimiento periódico para podar proofs DPoP expirados y filas terminales de agent activity; la entrega durable también tiene expiración y registros explícitos. Referencias: worker.ts, DpopProofs y DeliveryAttempts.

Brecha actual

Brio poda solicitudes pendientes solo en memoria. PostgreSQL conserva indefinidamente enrollments/pairings expirados o usados y devices revocados. Las features propuestas añadirán replay proofs, tickets, delivery attempts y terminal snapshots, aumentando el riesgo de crecimiento sin cota. No hay worker/cron de mantenimiento, batch budgets, métricas de filas eliminadas ni política documentada de retención.

Propuesta

1. Definir una política por tabla/clase: secreto efímero, registro operativo, auditoría de seguridad y datos de usuario.
2. Añadir un maintenance runner periódico que trabaje en batches acotados.
3. Podar primero enrollments/pairings expirados o usados tras su ventana de soporte; incluir después DPoP proofs, tickets, terminal activity y deliveries.
4. Mantener devices/agents activos y las ventanas de auditoría requeridas; anonimizar antes que borrar cuando corresponda.
5. Hacer ejecución multi-réplica segura con advisory lock/lease o SKIP LOCKED.
6. Registrar duración, filas, lag y fallos; alertar si el backlog supera el objetivo.
7. Añadir configuración de retention y dry-run/report para operadores.
8. No bloquear startup ni requests de usuario por un fallo de mantenimiento.

Criterios de aceptación

• Ninguna tabla efímera crece sin cota bajo carga sostenida.
• Dos réplicas no borran dos veces ni se bloquean entre sí.
• El job respeta batch/time budgets y reanuda después de fallo.
• Pairing/enrollment válido nunca se borra antes de su expiración/uso seguro.
• Retention de auditoría está documentada y testeada con límites temporales.
• Dashboard/health operativo permite detectar un maintenance backlog sin exponer datos sensibles.