[Relay][P0] Añadir un supervisor único de conexiones Relay en Mobile

[0bkevin]

Contexto auditado

El runtime compartido de T3 Code tiene un único owner por entorno para lifecycle, retries, connectivity, auth, probes y estado visible. Usa retry 3/4/8/16s, reset tras 30s estable, pausa offline sin consumir intentos, probe al foreground y estados separados de transporte/sincronización. Referencias: Connection Runtime y supervisor.ts.

Brecha actual

RelaySocketClient abre el socket de forma lazy por request. Si el socket cae, rechaza todo lo pendiente y se elimina del cache; la siguiente operación intenta abrir otro. No observa connectivity ni AppState, no prueba un lease al volver de background, no distingue fallos transitorios de auth/config, no expone retryAt/generation y varios componentes pueden inferir estado desde requests o datos cacheados.

Propuesta

1. Crear un supervisor persistente por environment/agent y convertirlo en el único owner del socket.
2. Modelar available/offline/connecting/reconnecting/connected/blocked/error, stage, attempt, generation, last failure y retryAt.
3. Consumir estado de red: offline libera socket, no ejecuta timers y reconecta inmediatamente al volver online.
4. Consumir lifecycle: foreground corto hace probe; suspensión significativa reemplaza el lease.
5. Clasificar auth/config como bloqueado hasta cambio de credencial/config o retry explícito.
6. Aplicar establecimiento con timeout, retry jittered/capped y reset solo tras conexión estable.
7. Separar transport health de sync/cache health; no mostrar “connected” hasta completar un probe/config inicial.
8. Al remover un agent, cerrar supervisor y limpiar socket, drafts/outbox/cache de ese agent únicamente.

Criterios de aceptación

• No existen dos loops de retry para el mismo agent/device.
• Offline no consume intentos ni mantiene backoff timers.
• Foreground con socket sano conserva la sesión; socket muerto reconecta sin esperar el primer backoff.
• Auth inválida no genera un retry storm y se desbloquea al refrescar credenciales.
• La UI muestra el estado real y una acción “Retry now”.
• Los requests nuevos siempre resuelven el lease vigente, no un objeto WebSocket capturado.
• Pruebas deterministas cubren offline startup, network wake, background resume, probe timeout, stable reset, credential wake, explicit removal y multi-agent.

Issue de ejecución para la parte de conexión/reconexión de #3.