MG-6 (parcial): sincronização agendada com lock em documento

132 casos verdes em 11 arquivos. O adaptador da fonte real veio portado com os
seus 13 casos, sem alterar nenhum: cota de 10 req/min, cache de 5 min, payload
malformado, timeout, 403 e 429.

A trava em processo deixou de existir

O defeito de 07/08 (PP-10-11) foi resolvido no NestJS com um Map em memória. Em
Functions isso não vale: cada invocação é um processo novo e duas podem estar em
máquinas diferentes. A trava virou documento tomado em transação — o único jeito
de duas máquinas concordarem sobre quem chegou primeiro — com validade, porque
Function que morre no meio deixaria o lock preso e a sincronização pararia em
silêncio, que é o modo de falha que esta story existe para eliminar.

Meu teste afirmava o mecanismo quando o que importa é o invariante

Ele exigia "uma das duas é ignorada" e falhou: com a fonte instantânea, a primeira
termina e solta o lock antes de a segunda tentar de novo, então as duas rodam em
sequência — e isso é legítimo, a segunda lê o estado novo e não acha nada para
mudar. Ficaram os dois casos: o invariante (uma alteração de placar no total) e o
mecanismo (com fonte lenta, sobreposição real, a segunda é ignorada).

Acoplamento que o teste expôs: sincronizar() dependia do app global do Admin SDK.
A instância do Firestore passou a entrar por parâmetro.

Decisão registrada: a sincronização não apura. Escreve o jogo, e os gatilhos de
MG-5 e MG-3 reagem. Se ela apurasse, existiriam dois caminhos para a mesma regra e
um envelheceria — e a correção manual do admin, que entra pela mesma porta, teria
comportamento diferente.

BE-3 (lembrete) e BE-4 (push) seguem abertas, e com elas FE-* e OPS-*: push
depende de app registrado no projeto real, que é MG-7.

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