fix: [TESIS-159] say a tenant is unknown only when the API answers 404

[LauAubert]

Ticket de Jira

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

ID provisorio: se reemplaza por la clave real al cargar la card en Jira. Card: cards/028.md. Sale de una auditoría de código del front (TESIS-89).

---

Descripción

El gate de arranque (TenantGate) mostraba «No encontramos esta empresa» ante cualquier falla de GET /tenant-config (if (slug === null || isError)). El contrato de tenant (TESIS-121, §3/§5) reserva esa pantalla para el 404, pero también la disparaban un 500 mientras la API se reinicia, un corte de red o una respuesta que no pasa el schema. Y tapaba la app entera aunque hubiera una config válida rehidratada de localStorage, sin forma de reintentar: la query tiene retry: false y staleTime: Infinity.

Repro en master: con la sesión abierta, recargar mientras la API se reinicia (o cerrar sesión: queryClient.clear() vuelve a pedir la config) → «La dirección desde la que entraste no corresponde a ninguna empresa configurada» hasta recargar a mano.

• Sólo un 404 (o la falta de slug) muestra la pantalla de empresa desconocida.
• Con config en el store, la app sigue aunque el pedido falle: el branding guardado es del mismo slug y la próxima carga lo vuelve a pedir.
• Sin config y con otra falla, una pantalla nueva «No pudimos conectarnos» con Reintentar (refetch).
• useTenantConfig reintenta una vez cualquier falla que no sea 404 (el 404 sigue sin reintento: no cambia el desenlace).
• Tests: app en pie con config guardada ante un 500, pantalla de reintento sin config, el botón vuelve a pedir; el caso 404 existente sigue igual.

---

Evidencia visual

Pendiente de captura.

---

Cómo probar

1. Con la API apagada y sin config guardada (ventana privada) → «No pudimos conectarnos» + «Reintentar». Prender la API y reintentar → entra.
2. Con la sesión abierta, apagar la API y recargar → la app se ve con su marca (los datos fallan cada uno con su error), no la pantalla de empresa desconocida.
3. ?tenant=ninguna → «No encontramos esta empresa», como siempre.

Verificación: npm run test (679 tests, 0 fallas), npm run lint, npm run format:check y npm run build limpios.

---

Impacto y consideraciones

¿Introduce breaking changes?
No

¿Requiere nuevas variables de entorno?
No

¿Afecta la arquitectura o genera un nuevo patrón?
No. Ajusta el gate a lo que ya decía el contrato de tenant.

🤖 Generated with Claude Code

[TomasMartin2004]

Revisado. Lo veo bien para implementar.

TenantGate mostraba «No encontramos esta empresa» ante cualquier falla de GET /tenant-config (if (slug === null || isError)), y encima tapaba la app entera aunque hubiera una config válida rehidratada de localStorage. El contrato de tenant (TESIS-121, §3/§5) reserva esa pantalla para el 404. Con el sistema desplegado en la VPS, un 500 mientras la API reinicia o un corte de red momentáneo son los modos de falla más probables en vivo, y los dos terminaban diciéndole al usuario que su empresa no existe. Es el peor mensaje posible: manda a buscar un problema que no está.

Lo que verifiqué

• Ahora distingue por status y sólo el 404 dice «no encontramos esta empresa». Confirmé que el cliente HTTP efectivamente expone status en el error (client.test.ts lo afirma con rejects.toMatchObject({ status: 401 })), así que la comprobación es contra algo que existe y no contra la forma que asume el mock.
• Una falla sin status (red, respuesta que no pasa el schema) cae también en «No pudimos conectarnos», que es lo correcto: no se sabe nada sobre si la empresa existe.
• Con una config ya rehidratada, la app sigue andando en vez de taparse. Ese es el caso que más vale en una demo: la API parpadea y la pantalla no se cae.
• «Reintentar» llama a refetch de verdad, con test. Antes el botón existía y no podía cambiar nada.

[TomasMartin2004]

Revisión del diff completo. El código es idéntico al que leí cuando los PRs estaban en draft —ningún commit nuevo—, así que lo que sigue es el veredicto formal.

✅ Aprobado

TenantGate mostraba «No encontramos esta empresa» ante cualquier falla de GET /tenant-config, y encima tapaba la app entera aunque hubiera una config válida rehidratada de localStorage. El contrato de tenant (TESIS-121, §3/§5) reserva esa pantalla para el 404.

Con el sistema desplegado en la VPS, un 500 mientras la API reinicia o un corte de red son los modos de falla más probables en vivo, y los dos terminaban diciéndole al usuario que su empresa no existe. Es el peor mensaje posible: manda a buscar un problema que no está.

Lo que verifiqué

• Ahora distingue por status y sólo el 404 dice «no encontramos esta empresa». Confirmé que el cliente HTTP efectivamente expone status en el error (client.test.ts lo afirma con rejects.toMatchObject({ status: 401 })), así que la comprobación es contra algo que existe y no contra la forma que asume el mock.
• Una falla sin status —red, respuesta que no pasa el schema— cae también en «No pudimos conectarnos», que es correcto: no se sabe nada sobre si la empresa existe.
• Con una config ya rehidratada, la app sigue andando en vez de taparse. Ese es el caso que más vale en una demo.
• «Reintentar» llama a refetch de verdad, con test. Antes el botón existía y no podía cambiar nada.