feat: [TESIS-135] let an operator ask for access from the browser

[TomasMartin2004]

Ticket de Jira

https://proyectofinalfrlp.atlassian.net/browse/TESIS-135

---

Descripción

TESIS-51 ("UI: Login y Registro") está cerrada, pero de su alcance sólo se implementó el login. La pantalla de registro no existía: POST /api/v1/auth/register está en la API desde TESIS-26 y no lo llamaba nadie, así que darse de alta era por backoffice o por curl. Este PR la agrega.

Crear la cuenta no inicia sesión. Nace sin aprobar y alguien la habilita desde el backoffice — es lo que dice la bajada del propio S02: «Solicitá acceso al espacio de operación de tu organización». Por eso la pantalla termina en un mensaje y no redirige al dashboard.

El 202 es el mismo se haya creado la cuenta o el email ya tuviera una. La API lo hace a propósito: si cambiara, registrarse serviría para averiguar qué emails existen. La pantalla de éxito conserva esa propiedad — nunca afirma que la cuenta se creó, dice «si el correo no tenía una cuenta…».

Dos desvíos de S02-Registro, los dos porque el dibujo es anterior al backend que existe hoy:

• Sin campo «Usuario». La tabla users no tiene esa columna: la identidad es el email, y el endpoint acepta email y password y nada más. Un campo que no se guarda en ningún lado es peor que su ausencia.
• El check de términos no enlaza a ninguna parte. El texto es el del diseño y frena el envío, pero las páginas legales todavía no existen en la app; mismo criterio que AuthShell con el «Centro de ayuda». Los documentos existen como entregable E9, sin publicar.

Como en el login, el encabezado de la tarjeta es el nombre del tenant y no el título del diseño: el branding por empresa (TESIS-121) es posterior a la pantalla dibujada.

• Ruta /register, pública y sin shell, como /login.
• useRegister + registerErrorMessage, con el mismo criterio que loginErrorMessage: el 422 muestra el texto del servidor (es el que dice qué campo está mal), el 429 habla de minutos, el resto cae en el genérico.
• Validación con Zod: email, contraseña de 6+ (el mínimo de Devise), confirmación que coincide y términos aceptados.
• Enlaces en los dos sentidos entre login y registro.
• 10 tests nuevos.

---

Evidencia visual

Antes	Después
/register no existía: el router redirigía a / y desde el login no había forma de llegar.	Formulario sobre AuthShell, con el branding del tenant, y pantalla de solicitud enviada al confirmar.

---

Cómo probar

1. npm run dev, ir a /login: abajo del botón está «¿No tenés cuenta? Crear cuenta».
2. Enviar con un email nuevo y una contraseña de 6+ → la pantalla dice que la solicitud quedó pendiente de aprobación, y no hay sesión iniciada.
3. Repetir con un email que ya tiene cuenta (admin@norte.com del seed) → exactamente la misma pantalla. Esto es lo que hay que verificar: la UI no puede distinguirlos.
4. En /admin (backoffice), aprobar la cuenta nueva y recién ahí se puede iniciar sesión con ella.
5. Contraseña de 5 caracteres, contraseñas distintas o el check sin tildar → el formulario ni sale a la red.
6. 11 intentos seguidos → 429, y el mensaje habla de esperar unos minutos.

---

Impacto y consideraciones

¿Introduce breaking changes?
No. Suma una ruta pública; nada existente cambia de comportamiento.

¿Requiere nuevas variables de entorno?
No.

¿Afecta la arquitectura o genera un nuevo patrón?
No. Feature auth existente, mismos patrones (React Query para la mutación, RHF + Zod para el formulario, copy en content.ts).

Lo que sigue faltando de TESIS-51, y por qué no entra acá: el login con Google. La API no tiene OAuth —Devise está configurado sólo con JWT— así que es una card con backend propio, no una pantalla. Tampoco existen recuperación de contraseña ni "remember me" en la API.

🤖 Generated with Claude Code

https://claude.ai/code/session_012xAtddb53LRNVLuyTXyELp

[LoLoo03]

Queres que reabra este PR?

[LoLoo03]

Lo corrijo, perdón que me colgué