feat: RBAC: Backend: Expor contrato de capabilities para o front derivado da policy

# Contexto
Após definir a matriz RBAC e centralizar a decisão em uma policy única, o front precisa consumir permissões efetivas já calculadas pelo backend para aplicar controle por ação/recurso sem duplicar regra de negócio.

### O que foi encontrado
Hoje o front tende a operar com role “crua” ou decisões locais. Sem contrato de capabilities:

- UI pode divergir da autorização real da API;
- regras de permissão ficam duplicadas entre front e backend;
- manutenção e evolução da autorização ficam mais arriscadas.

### Impacto no backend/produto
Sem capabilities derivadas da policy:

- ações podem aparecer habilitadas na UI e falhar só no backend;
- piora a experiência do usuário (feedback tardio);
- aumenta risco de inconsistência funcional entre telas e endpoints.

# Critérios de aceite

- O backend expõe um contrato de capabilities baseado na policy central (não em regra duplicada).
- O contrato cobre, no mínimo, recursos CMS e ações: listar, visualizar, criar, editar.
- O payload de capabilities é determinístico para o mesmo usuário/contexto.
- O contrato é versionável e documentado para consumo pelo front.
- Em ausência de permissão, a capability correspondente vem explícita como negada (não implícita).
- O cálculo de capabilities não altera comportamento de rotas públicas.
- O contrato mantém compatibilidade com regras já implementadas de 401 e 403 na API protegida.

# Notas técnicas

- As capabilities devem ser derivadas da policy central e da matriz RBAC, sem nova fonte de verdade.
- Definir formato estável de payload por recurso/ação para evitar acoplamento frágil no front.
- Aplicar princípio deny-by-default para permissões não mapeadas.
- Garantir observabilidade mínima para depuração de divergências entre role e capability efetiva.
- Preparar o contrato para expansão futura (novas ações/recursos) sem breaking change imediato.

### Fora de escopo (para evitar retrabalho)

- Reabrir autenticação básica, login, redirect ou acesso negado do front.
- Reespecificar role simples em sessão/JWT já tratada nos cards anteriores.
- Reimplementar guard básico de rotas CMS já coberto.

# Dependências

- Depende de: matriz RBAC por ação/recurso definida.
- Depende de: policy central única implementada.
- Desbloqueia: cards de front para consumo de capabilities e aplicação de permissão granular na UI.

No files or tests are named. Start by locating the central policy and RBAC matrix referenced in the issue, then trace the protected API entry point that should expose the capabilities contract. Done means a documented, versionable and deterministic payload explicitly represents allowed and denied CMS actions without changing public routes or existing 401/403 behavior.

Vom Indexierungsmodell aus dem Issue-Text verfasst.