Feat(projects): Project Server Keys

[liamburja]

Historia de usuario
Como administrador de un proyecto, quiero generar credenciales de servidor (machine-to-machine) scoped a ese proyecto, para que integraciones automatizadas (CLI, backends de state-iac, CI/CD) puedan autenticarse y operar solo dentro de ese proyecto, sin usar una sesión de usuario personal.

Contexto
Depende de la Issue 3 (Project Settings) para la ubicación en UI, y de la Issue 5 (Project Roles) para definir qué permisos tiene la key dentro del proyecto. Como la tabla api_keys ya existe (ligada a userId) pero el mecanismo de autenticación por key nunca se implementó, esta issue cubre ambas cosas: el scoping a proyecto y la validación real de la key en las peticiones.

Extendemos ApiKeyEntity con un projectId opcional (mutuamente excluyente con userId), reutilizando toda la lógica de prefix/hash/rotación ya modelada.

Criterios de aceptación

• Middleware de autenticación por API key: aceptar Authorization: Bearer en hooks.server.ts y resolver la identidad (proyecto + rol) a partir del hash — hoy no existe ningún camino de auth que no sea la cookie de sesión.
• Desde Project Settings, sección "Server Keys": el admin del proyecto puede generar una nueva key.
• Al crear la key se le asigna un Project Role (Issue 5), que determina sus permisos dentro del proyecto.
• La key en claro se muestra una única vez al crearla; después solo se ve el keyPrefix (mismo patrón que las keys de usuario).
• Listar, rotar y revocar keys del proyecto.
• Una key revocada/rotada deja de autenticar inmediatamente.
• Las peticiones autenticadas por Project Server Key quedan limitadas a ese proyecto: no acceden a datos de otros proyectos ni a /settings de admin global.
• Se actualiza lastUsedAt en cada uso.

Notas técnicas

Reutilizar/completar ApiKeysService y ApiKeyRepository (apikeys.service.ts, apikey.repository.ts), ambos scaffoldeados pero sin implementación.
Extender ApiKeyEntity en schemas.ts con projectId nullable + constraint de que exactamente uno de userId/projectId esté presente.
El nuevo path de autenticación en hooks.server.ts convive con el de cookie de sesión existente, sin romperlo.

Fuera de alcance

Completar las Server Access Keys de usuario (global) si quedan pendientes — posible issue conjunta ya que comparten infraestructura.
UI de scopes granulares por key más allá del Project Role asignado (p.ej. limitar a un solo módulo) — se podría añadir después si hace falta.