[Relay][P0] Sacar el tráfico normal del Relay con endpoints gestionados por agente

[0bkevin]

Contexto auditado

• T3 Code/T3 Connect: b4be33f0747445f1c9df126e932c7b9792f322d5 (2026-08-23).
• Brio main: c19d21ea4fede2376c5141f2cf07706b4c8f7355.
• Cambios de robustez actuales: 967f4e5610f631bac9e4b9e69b07d956185491ca.

T3 Connect usa el relay como plano de control: enlaza entornos, provisiona un endpoint gestionado y entrega credenciales breves; el tráfico HTTP/WebSocket normal va directo entre cliente y entorno. Referencias: relay README, EnvironmentConnector y ManagedEndpointProvider.

Brecha actual

Brio enruta todas las solicitudes y streams Hermes por el hub WebSocket en memoria de server.go. El commit actual limita colas, reemplaza leases obsoletos, añade pings y expiración, pero no cambia estas propiedades:

• Relay sigue siendo cuello de botella de ancho de banda y latencia.
• hub.agents, solicitudes pendientes y límites son locales al proceso.
• Dos réplicas pueden recibir Mobile y connector distintos sin poder encontrarlos.
• Reiniciar/deployar Relay interrumpe trabajo activo.
• Sticky routing no resuelve peers que aterrizan en réplicas diferentes.

Propuesta

1. Provisionar un endpoint por agente mediante un provider intercambiable, empezando por Cloudflare Tunnel.
2. Persistir allocation, hostname, provider IDs, estado de readiness y lifecycle de release/deprovision.
3. Hacer que el connector mantenga el origen en loopback y lance/supervise el túnel saliente.
4. Convertir Relay en discovery/control plane: list, link, status, connect, release y unlink.
5. Usar challenges con nonce y respuestas firmadas para health y credential mint; no seguir redirects y aplicar timeout.
6. Entregar al cliente endpoint + credencial efímera y conectar el tráfico normal directamente.
7. Mantener el relay WebSocket actual como fallback temporal detrás de capability/feature flag y migración reversible.
8. Reconciliar teardown externo después de revocar en base de datos, de forma reintentable e idempotente.

Criterios de aceptación

• Una sesión directa ya establecida sobrevive a reinicios o deploys del Relay.
• Dos o más réplicas pueden servir list/status/connect sin afinidad de WebSocket.
• El Relay no recibe payloads normales de chat, archivos ni streams.
• Provision, release y unlink son idempotentes; fallos parciales se reconcilian sin dejar túneles huérfanos.
• Solo se aceptan hostnames del dominio gestionado y orígenes loopback permitidos.
• Health/mint verifican issuer, audience, nonce, expiración, agent ID, clave y payload.
• Hay pruebas E2E de link → connect directo → reconnect → unlink, además de fallos de provider.
• La UI explica cuándo usa fallback y cuándo el endpoint todavía se está provisionando.

Relacionado con #3 y #5, pero esta issue cubre específicamente la topología y lifecycle del data plane.