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.