Obrigado pela leitura cuidadosa. Os três pontos valem.

1. Rotação da chave: no relatório, a primeira correção já é "rotacione a chave do provedor; a antiga foi parar no navegador" (report/findings.md). Concordo com a formulação: commit limpo com chave velha ativa continua sendo conta esvaziada.

2. Limite por conta: o bloqueio trivial (5 erros a cada 15 min contra um e-mail conhecido) é a consequência conhecida de um limite que vive só no banco; está em "O que eu não corrigi", e a correção real é limite por IP/fingerprint na borda com atraso progressivo em vez de pausa dura. Sobre contenção: o advisory lock é por conta e transacional, então meia dúzia de e-mails viram meia dúzia de filas e o que esgota é o pool. Num app real o contador sai do banco (memória/Redis com janela) e a transação fica só para o estado da conta.

3. O "confia em mim" do PGlite: rodei hoje a mesma suíte contra Postgres 16 em Docker (node-postgres, pool de 10 conexões, arquivos em sequência): 10 arquivos e 42 testes passam, inclusive os 30 logins simultâneos, os dois checkouts no mesmo instante e os cadastros paralelos. Está em npm run test:pg e na seção Limits do README. O que isso não prova: que tirar o lock faria um teste falhar. Esse experimento (versão corrigida sem o lock) é o próximo passo.

Sobre o brinquedo controlado: concordo. O repositório é uma amostra didática; um app de verdade é o que você descreveu, e por isso o trabalho começa com mapa e escopo antes de qualquer correção.