Feat(projects): Project OIDC

[liamburja]

Historia de usuario
Como administrador de un proyecto, quiero configurar un proveedor OIDC de confianza (p.ej. GitHub Actions), para que mis pipelines se autentiquen contra ese proyecto usando tokens de corta duración, sin tener que generar ni rotar Server Keys estáticas (Issue 6).

Contexto
Complementa la Issue 6: las Server Keys son credenciales estáticas de larga vida; OIDC es la alternativa "sin secretos" (federación de confianza vía token firmado por un proveedor externo). Se scopea a nivel de Project y, al igual que las Server Keys, la petición autenticada se mapea a un Project Role (Issue 5) para determinar sus permisos.

Preguntas de diseño a confirmar ⚠️

¿Qué proveedor(es) cubre la v1? Sugiero empezar solo por GitHub Actions OIDC (el caso de uso más común) y dejar el modelo abierto a añadir GitLab CI u otros después.
¿Cómo se definen las reglas de "trust policy" que mapean claims del token (p.ej. repository, ref, environment en GitHub Actions) a un Project Role? Propongo reglas simples de match exacto/wildcard sobre esos claims, ampliables más adelante.
Criterios de aceptación

• Nueva sección "OIDC" en Project Settings: el admin añade uno o más proveedores de confianza indicando issuer URL, audience esperada y reglas de mapeo de claims → Project Role.
• Nuevo punto de entrada de autenticación que acepta un id_token OIDC en Authorization: Bearer, valida su firma contra las JWKS del issuer, verifica audience y expiración, y comprueba que los claims cumplen alguna regla configurada.
• Si el token es válido y matchea una regla, la petición queda autenticada scoped a ese proyecto con los permisos del Project Role mapeado, sin persistir ningún secreto.
• Token inválido, expirado o sin match de reglas → 401/403.
• El admin puede listar y eliminar configuraciones OIDC del proyecto.
• Registro mínimo de auditoría por autenticación OIDC (issuer, subject/claims relevantes, timestamp) — al no existir una "key" física, es la única forma de trazar quién entró.
• Guía how-to de ejemplo para configurar esto desde GitHub Actions.

Notas técnicas

Este punto de entrada convive con el de la Issue 6 (Server Keys) y con la cookie de sesión en hooks.server.ts; diferenciar por formato de token (JWT de 3 partes vs API key con prefijo propio).
Hace falta añadir una librería de verificación JWT/JWKS (no hay ninguna en package.json hoy — evaluar jose u otra).
No hay revocación instantánea de un token ya emitido antes de su expiración natural (eso lo controla el proveedor externo); mitigar recomendando exp cortos, no prometer revocación inmediata en esta issue.

Fuera de alcance

Login humano vía OIDC para entrar a la propia UI de gitvault (eso es un concepto distinto, ya cubierto por Google SSO/SAML en /settings/authentication).
Soporte multi-proveedor genérico en la v1.