[Relay][P1] Persistir cuotas por cuenta y límites compartidos entre réplicas

[0bkevin]

Contexto auditado

T3 Connect aplica un límite persistente por usuario antes de provisionar túneles gestionados; el default actual es 3 y la comprobación participa en el lifecycle de link. Referencia: ManagedTunnelLimits.

Brecha actual

Brio limita frames, pending y rate por proceso, pero no limita de forma persistente cuántos agents, devices o futuros túneles puede crear una cuenta. Los fixed-window limiters se reinician con el proceso y se pueden repartir entre réplicas. Un reconnect storm o abuso distribuido evade el presupuesto local; además la UI no puede explicar uso/capacidad.

Propuesta

1. Definir cuotas por plan/cuenta para agents activos, managed tunnels, devices y operaciones sensibles.
2. Reservar/provisionar capacidad de forma transaccional para evitar carreras de dos links simultáneos.
3. Añadir rate limiting compartido para auth, enrollment, pairing, recovery, connect y publish, con claves y ventanas por IP/account/device según riesgo.
4. Mantener límites locales de seguridad para colas/sockets además del límite compartido.
5. Devolver error tipado con límite, uso, reset/retry time y Retry-After.
6. Exponer uso/capacidad en Mobile antes de crear enrollment; permitir unlink/revoke aunque la cuenta esté sobre cuota.
7. Añadir overrides administrativos auditados y expirables, sin hardcodear planes en el cliente.
8. Diseñar counters/reconciliación para fallos parciales de provision/deprovision.

Criterios de aceptación

• Dos requests concurrentes no pueden exceder la misma cuota.
• Reinicios o cambio de réplica no reinician límites persistentes.
• El cliente recibe un mensaje accionable y fecha de retry, no un 500.
• Operaciones de cleanup siempre quedan disponibles.
• Límites locales y compartidos fallan cerrados bajo saturación sin bloquear health/unlink.
• Tests cubren carreras, rollback, provider failure, over-quota existente y multi-replica.

Complementa hardening de #5 y la topología de #43.