Push entregue e backend publicado em produção

App Android registrado em bolao-raro-4382d, 31 Functions no ar em
southamerica-east1, rules e índices publicados. O sincronizarComAFonte e o
lembrarPrazoFechando estão no Cloud Scheduler — o que fecha a PP-10 OPS-1, aberta
desde o começo do projeto.

O push entrega, não cria

O gatilho escuta usuarios/{uid}/avisos e manda o que já está lá. Se a entrega
falhar, ninguém perde informação: o aviso continua no app. É o que mantém PP-8-08 e
PR-7-09 verdadeiros com o push desligado, e é por isso que permissão negada é
resposta e não erro. Token que o FCM recusa em definitivo é apagado na hora — app
desinstalado deixa token que faz toda entrega futura gastar tentativa e voltar erro.

Um defeito grave que o teste de push encontrou de lado

Ao escrever o teste do registro, o cold start apareceu quebrado: restaurar() ainda
perguntava "há accessToken guardado?", e esse campo era a credencial do backend
antigo. Com o Firebase Auth ninguém escreve mais nele — então a pergunta tinha uma
resposta só, null, e o app mandava para o login todo mundo, sempre, logado ou não.

O teste que deveria pegar isso passava: ele injetava um token no armazenamento,
cenário que não existe mais em produção. É a mesma armadilha de MG-7-64 — cenário
impossível de alcançar pelo produto — agora do lado do app. Quem sabe se há sessão
passou a ser a camada de autenticação.

O .env das Functions virou .env.local

O deploy publica o .env como variável de ambiente comum, e o token colidiu com o
Secret Manager: "Secret environment variable overlaps non secret". O .env.local é
lido só pelo emulador e nunca é publicado — que é exatamente o que se quer de um
segredo local. Documentado no README com a tabela das duas casas.

E a rule souAdmin saiu: ela ficou sem uso quando toda ação de admin virou callable,
e rule morta é armadilha — alguém lê e acha que existe checagem ali.

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