0.3.2 — el módulo ya no deja el panel del sitio sin acceso

Crítico: el módulo dejaba el panel del sitio sin acceso

Con el módulo activo, /wp-admin respondía 403 a todo el mundo, administrador incluido, y el registro
se llenaba de avisos de map_meta_cap. La causa: el tipo de contenido declaraba sus capacidades por
entrada con capacidades globales ('read_post' => 'read', 'edit_post' => 'convoca_manage_courses').
WordPress copia esos valores a $post_type_meta_caps, y desde ahí cualquier current_user_can('read') sin
id de entrada se resuelve como do_not_allow.

Medido en la demo, con el módulo activo y desactivado:

con el módulo ACTIVO:      map_meta_cap('read') = ["do_not_allow"]   user_can(read) = 0
con el módulo DESACTIVADO: map_meta_cap('read') = ["read"]           user_can(read) = 1

Corregido

• Las tres capacidades por entrada pasan a tener nombre propio (convoca_read_curso, convoca_edit_curso,
  convoca_delete_curso) y un filtro map_meta_cap las traduce: leer es read, editar y borrar son
  convoca_manage_courses (CPT_Base::bridge_meta_caps()).
• Mismo defecto corregido en el tipo de contenido de convocatorias.

Añadido

• MetaCapsTest: falla si alguna de las tres vuelve a llamarse como una capacidad global.

Verificación

• Panel en la demo con navegador real: /wp-admin/ 200, «Cursos» 200, «Entregas» 200 con su tabla
  (antes, 403 en las tres).
• Suite E2E de Playwright contra la demo: 14/14 en verde, incluido el test del panel del profesorado.
• Puerta local: 6 ok / 0 fallos · unidad 163 pruebas · integración 10 pruebas / 50 aserciones.

Alcance

Cualquier sitio que activara la 0.3.x perdía el panel. En el ecosistema solo estaba activo en la demo;
Lugg y biodevas lo tienen instalado pero inactivo (comprobado).

Issue: #1 (cerrado con este arreglo).