feat: administradores por proyecto y Configuracion solo para superadmin

- Un proyecto puede tener uno o mas administradores (role_in_project=
  'admin' en project_members), independiente del rol global del usuario.
  Nuevo PUT /api/projects/:id/members/:userId/role; canWriteProject lo
  reconoce ademas del comportamiento previo (admin/superadmin/it_manager
  global, o project_lead miembro). UI: casilla al agregar miembro + boton
  de escudo para promover/degradar (nunca toca al Dueño).
- Menu "Configuracion" (apariencia, catalogos, SMTP) visible y accesible
  solo para el superadmin: oculto en el nav y con guarda en la ruta
  /configuracion para quien la teclee directo. Escritura de catalogos
  restringida de [superadmin, admin] a solo superadmin para que el
  backend sea consistente con la UI.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

BASE_DE_DATOS.md

@@ -71,6 +71,11 @@
   "eliminarlo" — se oculta de listados/dashboard, sigue en BD). Borrado físico (`DELETE`, arrastra
   actividades/comentarios/adjuntos por `ON DELETE CASCADE`) solo vía `permanentlyDeleteProject`,
   solo superadmin, y solo sobre un proyecto que ya tiene `deleted_at` (dos pasos, nunca directo).
+- `project_members.role_in_project`: `'owner'` (dueño, se asigna solo al crear el proyecto, nunca
+  se toca desde el endpoint de rol), `'admin'` (administrador **de ese proyecto puntual** — un
+  proyecto puede tener varios, otorgado por quien ya puede escribir el proyecto, sin importar el
+  rol global de a quién se lo otorgan), `NULL`/otro = miembro sin permisos de escritura (salvo que
+  además sea `project_lead` global, comportamiento previo sin cambios).
 - Empresa asumida única (no hay tabla `companies` en el MVP).
 - Producción siempre usa `192.168.222.32`. Desarrollo siempre usa `192.168.222.20`. No mezclar.