[Relay][P0] Separar liveness/readiness y comprobar PostgreSQL

[0bkevin]

Contexto auditado

El health handler de T3 Connect ejecuta SELECT 1 y devuelve error si la base de datos no está disponible: Api.ts.

Se revisaron Brio main y el commit actual 967f4e5610f631bac9e4b9e69b07d956185491ca.

Brecha actual

GET /health en server.go siempre responde 200 { ok: true } después de contar peers/pending en memoria. No prueba el Store/PostgreSQL. Un proceso vivo con DB caída sigue entrando en balanceo y acepta tráfico que luego falla en auth, enrollment, recovery y presence. El endpoint también mezcla salud con estadísticas internas públicas y no representa estado de draining/migrating.

Propuesta

1. Exponer liveness de proceso separada de readiness.
2. Readiness debe hacer Ping/SELECT 1 con timeout corto y comprobar que migraciones requeridas están aplicadas.
3. Marcar not-ready antes de graceful shutdown/drain y antes de cerrar sockets.
4. Mantener estadísticas detalladas en métricas/autenticación, no necesariamente en el health público.
5. Documentar probes, timeouts, failure thresholds y grace periods del deployment.
6. Devolver errores JSON estructurados y request/trace ID sin filtrar DSN ni errores internos.

Criterios de aceptación

• DB caída: liveness sigue 200, readiness pasa a 503 dentro del timeout.
• DB recuperada: readiness vuelve a 200 sin reiniciar.
• Durante migración incompatible o drain no se recibe tráfico nuevo.
• La comprobación no puede bloquear indefinidamente ni agotar el pool.
• MemoryStore/dev mode conserva un readiness explícito y testeado.
• Tests cubren DB timeout, recuperación, shutdown race y respuesta sin datos sensibles.