MG-2: modelo no Firestore e participação aplicada pelo banco

28 casos de security rule verdes. A autorização deixa de ser código de aplicação
e passa a ser regra do banco: quem não participa não lê, quem saiu perde o acesso
na hora, participante não se promove, e `createdBy` é imutável — que é o que
sustenta "criador é admin permanente" (CC-8) por um caminho que nenhum teste de
CC-8 cobria.

O schema vive em functions/src/modelo.ts: o Firestore não tem schema, então esse
arquivo é o contrato que as rules assumem. Rule que consulta `role` e documento
que grava `papel` é furo de autorização silencioso.

Duas correções de desenho, as duas achadas por teste que falhou

- "Meus bolões" não pode ser consulta de grupo em `membros`. Falhou duas vezes e
  cada falha ensinou: primeiro que consulta de grupo não é avaliada pelo match
  aninhado (caiu no deny genérico), depois que no `list` o {uid} do caminho não é
  vinculado e a rule não inspeciona o `where` — não há como provar que a pessoa
  pediu só o que é dela. Virou índice sob o próprio usuário, com o resumo dentro:
  uma leitura, rule sem get(). O spike foi corrigido.
- O displayName mudou de lugar por causa do sigilo: ler o perfil de cada
  participante seria leitura extra e furaria a regra de não ler perfil alheio.

18 dos 28 casos verificam recusa, de propósito: no NestJS negar era uma linha de
service com e2e; aqui é a ausência de uma cláusula em rule — e ausência não
aparece lendo o arquivo, só falhando um teste.

Limite registrado: o emulador não exige índice composto, então consulta que
precisaria de um passa aqui e falha em produção. Entra como verificação
obrigatória de MG-8 contra o projeto real.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>