Manage projects, members and services through the API

/api/v1/projects, /members and /services: create, list, show, update,
delete and restore, with the panel's own rules — so the MCP server can
load the collective's work, people and offer without anyone retyping
them into forms. The MCP server picks the tools up from openapi.yaml.

- Relations travel as ids and are replaced whole when sent, left alone
  when not: a project's technology_ids, service_ids and members with
  each one's role; a member's technology_ids; a service's
  technology_ids and project_ids. Record and relations are saved in
  one transaction.
- Publishing stays a permission of its own. Without projects.publish
  or services.publish, published_at, unpublish_at and is_published are
  refused — the fields the panel disables for the same people.
- MemberPolicy still lets someone edit their own profile.
- Uploads accept `for: projects` and `for: members`, landing where the
  panel's own upload fields put them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

README.md

@@ -1263,11 +1263,21 @@ POST   /api/v1/pages/{page}/restore
 GET    /api/v1/users               PATCH para roles, is_active, locale
 GET    /api/v1/roles               solo lectura
 GET    /api/v1/roles/catalogue     catálogo de permisos agrupado
+       /api/v1/projects            CRUD + restore; relaciones por ids:
+                                   technology_ids, service_ids, members[{id, role}]
+       /api/v1/members             CRUD + restore; links (etiqueta → URL), technology_ids
+       /api/v1/services            CRUD + restore; technology_ids, project_ids
        /api/v1/technologies        CRUD completo; filtros: category,
                                    radar_ring (none = fuera del radar), search
 POST   /api/v1/media               subir una imagen (fichero o URL)
 ```
 
+Publicar sigue siendo un permiso aparte, como en el panel (donde esos campos
+salen desactivados): sin `projects.publish` o `services.publish`, la API rechaza
+`published_at`, `unpublish_at` e `is_published`, así que quien puede escribir
+algo no puede sacarlo a la web solo. Las relaciones enviadas sustituyen a las
+que había, y las no enviadas no se tocan; todo se guarda en una transacción.
+
 `GET /v1/me` devuelve el array `permissions`: úsalo para construir la UI del
 cliente en vez de comprobar nombres de rol.