v0.3.2 — corrida de leitura da trilha no teste do watchdog

Fecha uma corrida em tests/watchdog-wired.test.ts. v0.3.0 e v0.3.1 não
foram movidas.

Corrigido

• Um teste podia reprovar depois de o produto ter feito tudo certo. Visto
  uma vez, na sala limpa da tag v0.3.1: o caso "NAVEGADOR MORTO por baixo"
  passou em todas as asserções sobre o comportamento — detected.browser_dead
  subiu, recovered.browser_dead subiu, o lease foi solto — e reprovou três
  linhas abaixo, em:

  AssertionError: o watchdog agiu sem deixar linha no audit
  

  O watchdog tinha agido. A trilha é escrita de forma assíncrona; a leitura
  era síncrona e imediata, sem espera nenhuma. Sob disputa, a escrita perde a
  corrida e o teste lê um arquivo que ainda não recebeu a linha.

  O mais claro é que o mesmo arquivo, vinte linhas acima, já esperava desse jeito
  pelo status da sessão (for (...) await dormir(100)). A espera existia para
  um efeito e faltava para o outro.

  trilhaAte() passa a esperar a linha aparecer, com prazo. Isso não
  enfraquece a asserção: se a linha nunca aparecer, ela reprova ao fim do
  prazo, com a mesma mensagem. O que deixa de acontecer é vermelho causado por a
  máquina estar ocupada — e vermelho que não distingue defeito de carga ensina a
  ignorar vermelho.

O que está provado e o que não está

Provado: a corrida existe no código — leitura síncrona imediata de um arquivo
escrito de forma assíncrona, sem espera, ao contrário da asserção vizinha.
Provado: a falha aconteceu, com essa mensagem, numa execução real da suíte
completa a partir do clone da tag.

Não provado: que a correção elimina aquela ocorrência específica. A falha não
foi reproduzida sob demanda — 8 execuções isoladas e 6 sob carga de CPU
(load average 28,9) passaram todas. A carga sintética de CPU não recria a
disputa da suíte completa, que envolve vários Chromium e pressão de sistema de
arquivos.

A correção se sustenta por inspeção, não por reprodução, e este parágrafo existe
para que ninguém leia mais garantia do que foi medido.