MG-3: sigilo do palpite e prazo aplicados pelo banco

34 casos verdes (26 de security rule, 8 de integração com a Function), suíte de 66.
São as duas regras que, quebradas, corrompem o bolão — e as duas deixaram de ser
código de aplicação.

Descoberta que muda o app: rules não são filtros

MG-3-07 falhou com "Property userId is undefined on object. for 'list'", que
parecia bug de rule e não era. Numa consulta, a rule é avaliada contra a consulta:
o `where` precisa provar o acesso. Filtrar palpites só por matchId deixa userId e
matchFinished indefinidos para o avaliador, e ele recusa — mesmo que todos os
documentos devolvidos fossem legíveis.

Consequência concreta para MG-7: a tela de "palpites de todos" precisa consultar
matchId == X E matchFinished == true. O caso ficou com as duas metades (sem o
filtro falha, com ele passa) para a exigência não se perder.

O risco do sigilo mudou de lugar, e os testes seguem ele

No NestJS era filtro em consulta: código certo, regra válida sempre. Aqui é um
campo que alguém precisa virar, e esse alguém é uma Function. Então os casos
testam a transição: o apito não libera, FINISHED sem placar não libera, e
MG-3-30 verifica a Function não rodando — palpite fica secreto a mais, nunca
exposto antes. O inverso não tem como acontecer: só a Function escreve o campo.

Defeito no teste, não no produto: os dois casos negativos falharam por timeout do
Jest (esperar 5s com limite de 5s). Caso negativo com orçamento de tempo errado
parece defeito de regra, e o reflexo de mexer na regra é forte.

Limite registrado: o índice de grupo em palpites.matchId está declarado e não
verificado — o emulador não exige índice e a Function de sigilo depende dele.
Verificação obrigatória em MG-8.

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