✨ feat(api/auth): multi-provider new template

[ChristianSanchez25]

📝 Descripción

Este PR implementa un sistema de autenticación configurable basado en proveedores (Providers), siguiendo los lineamientos de la Arquitectura Hexagonal. Separa la lógica de autenticación en casos de uso dedicados para Sign In y Sign Up, e incluye el refactor necesario para corregir violaciones a la regla de dependencias entre capas, además de implementar pruebas unitarias completas.

🚀 Cambios Principales

• Casos de Uso de Autenticación: Se añadieron SignInWithProviderUseCase y SignUpWithProviderUseCase para manejar la lógica central de registro e inicio de sesión de usuarios.
• Sistema de Proveedores (Ports/Adapters): Se crearon puertos (AuthProviderPort, AuthProviderFactoryPort) e implementaciones (CredentialsAuthProvider, AuthProviderFactoryImpl) para resolver dinámicamente los distintos proveedores de autenticación.
• Configuración y Entorno: Implementación de las variables de entorno (.env.example) para los secretos de autenticación e integración limpia de alias de rutas en el tsconfig.json.
• Pruebas Unitarias (Tests):
  • Se agregaron suites de pruebas para el registro (sign-up.test.ts) y el login (sign-in.test.ts).
  • Se refactorizaron las pruebas de usuarios (users.test.ts).
  • Se corrigieron los problemas de tipado estricto en los mocks de TypeScript (como la implementación de getProviderType requerida por AuthProviderPort) y errores de sintaxis en Jest/Vitest.

🧪 Cómo probar

• Clonar la rama y ejecutar npm install.
• Configurar el archivo .env tomando como base el .env.example.
• Correr el servidor de desarrollo utilizando npm run dev.
• Para probar la integridad del código, ejecutar la suite de tests:

  npm run test
  # Todas las 7 pruebas en 3 archivos (sign-up, sign-in, users) deben pasar exitosamente.
  
  

[sentry]

Bug: The sign-up request schema in SignUpWithProviderRequest.ts incorrectly requires firstName and lastName, causing validation errors for users who omit them, even though the system is designed to allow it.
_{Severity: HIGH}

Suggested Fix

In SignUpWithProviderRequest.ts, update the Zod schema for firstName and lastName. Replace the .min(1) validation with .optional() to correctly mark these fields as optional, aligning the API contract with the backend logic and frontend schemas which are designed to handle their absence.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location:
apps/api/src/modules/auth/infrastructure/web/dto/SignUpWithProviderRequest.ts#L7-L9

Potential issue: The Zod schema in `SignUpWithProviderRequest.ts` incorrectly requires
`firstName` and `lastName` to be non-empty strings by using `.min(1)`. This contradicts
the intended design where these fields are optional, as evidenced by the
`CreateUserCommand` which accepts them as optional, the `CreateUserService` which
handles null values, and frontend schemas where they are marked as `.optional()`. This
discrepancy will cause the API to return a 400 Bad Request error for users who attempt
to sign up without providing a first or last name, blocking a valid user flow.

_{Did we get this right? 👍 / 👎 to inform future reviews.}