fix(testes): elimina a flakiness de core.test.ts (espera por tempo real e isolamento de authDir)

[Clintonrocha98]

Contexto

tests/collector/core.test.ts falhava de forma intermitente, em testes diferentes a cada rodada:
loggedOut limpa o authDir e reconecta, webhook != null liga o coletor, repassa cada evento p/ saveEvent, connection.update: connecting e qr propagam, group-participants.update invalida o diretório, entre outros. Medido antes do conserto: 2 de 5 rodadas da suíte completa falhavam.

Rodando só esse arquivo, 15/15 passavam — o que explica por que o problema parecia aleatório.

Causa raiz

O helper emit() esperava o ev.process do socket falso ser registrado contando 100 voltas do
event loop, como se isso fosse proxy de tempo:

for (let i = 0; i < 100 && !processCb; i++) await new Promise((r) => setImmediate(r))
assert.ok(processCb, 'ev.process não foi registrado')

Mas connect() faz I/O de disco real (useMultiFileAuthState: stat/mkdir/readFile via libuv). Com a
suíte inteira rodando (~24 arquivos em processos concorrentes disputando disco e CPU), 100
setImmediate passam em ~2ms de relógio — tempo insuficiente para a I/O terminar. Evidência
capturada com instrumentação temporária:

connect() start authDir=/tmp/core-test-.../baileys_auth_info
emit: esperou 100 ticks / 2ms, processCb=false     ← orçamento estourado
TEST START "webhook != null liga o coletor..."
✖ loggedOut limpa o authDir e reconecta
useMultiFileAuthState done +25ms                   ← terminou depois da falha

Falha por relógio, sem nenhum bug de lógica. UV_THREADPOOL_SIZE=64 não resolveu, descartando
"threadpool saturado" como causa isolada.

Agravante: todos os testes usavam o mesmo authDir relativo ('baileys_auth_info', com o cwd
fixado uma vez no topo do arquivo). Como stop() não esperava o connect() em voo, uma conexão
sobrevivia ao teste que a originou e ia disputar o mesmo diretório — e o mutex de arquivo do Baileys,
que é module-level por caminho — com o teste seguinte.

O que muda

tests/collector/core.test.ts

• waitUntil(cond, timeoutMs = 5000): espera por tempo real (Date.now()), não por ticks.
• nextAuthDir(): cada teste ganha a própria subpasta (auth-N/baileys_auth_info).
• Nenhuma asserção foi enfraquecida, pulada ou removida — a cobertura é idêntica.

src/collector/core.ts (código de produção, então justificando)

• connectPromise aponta para o connect() em voo mais recente (inicial ou reconexão via close).
• Guard if (stopped) return em connect(), após os awaits de auth state e versão, antes de criar o
  socket e registrar ev.process.
• stop() aguarda esse connect(), com teto de 2s.

O motivo de mexer em produção: sem isso, stop() retornava enquanto um connect() (ou uma
reconexão pós-close) seguia por trás criando authDir, abrindo socket e registrando handlers
depois que o chamador já considerava o coletor parado. Não é só ruído de teste — um stop() durante
ciclo de reconexão não garantia que o coletor parasse de tentar falar com o WhatsApp.

O teto de 2s existe porque connect() contém uma chamada HTTP (fetchLatestBaileysVersion).
Numa rede ruim ela fica pendurada, e um stop() preso atrás dela nunca chegaria ao
outbox.close() — o checkpoint do WAL do SQLite —, caindo no forceMs do shutdown.ts (saída com
código 1). Seria pior que o comportamento anterior, em que o outbox fechava imediatamente. Com o
teto, a garantia de quiescência vale no caso normal (o connect() só terminando de resolver, que é
o caso dos testes) e o shutdown não fica hostage de rede.

Verificação

• 25 rodadas consecutivas da suíte completa após o conserto dos testes: 25/25 passaram.
• 10 rodadas adicionais após o teto no stop(): 10/10 passaram (246 testes).
• tsc --noEmit -p tsconfig.test.json: limpo.
• Antes: 2/5, 2/10, 2/20 rodadas falhavam, sempre com a assinatura ev.process não foi registrado.

Limitação conhecida

O teto de 2s no stop() não tem teste: fetchLatestBaileysVersion é importado direto no módulo e
não é injetável, então simular a chamada pendurada exigiria um refactor de injeção fora do escopo
deste conserto. O caminho normal (connect resolvendo antes do teto) está coberto pelos 15 testes que
chamam startCollectorCore e stop().

O waitUntil tem timeout finito (5s): numa máquina absurdamente sobrecarregada a falha ainda seria
teoricamente possível — mas por tempo real esgotado, não por um número arbitrário de ticks.