feat: implement Pillars 2-4 and fix a production false-positive in Pillar 1

Pillar 1 v1.1 (shipped earlier) flagged benign browsing bursts as
beaconing: on short captures, grid periods longer than the observed
span never complete a cycle, so significance saturates to 1 and the
score sticks at exactly 0.5. v1.2 caps the grid at a third of the
observed span, requires a minimum number of completed cycles, and
excludes protocols that are periodic by nature (NTP, DNS, mDNS,
ICMP). Validated against 300 seeds per scenario: false positives on
bursty traffic drop from the 290-300/300 that v1.1 produced to 0/300,
with every beacon-detection scenario scoring unchanged.

Add Pillar 2 (persistent/long-lived sessions, with Zeek's fragmented
TCP sessions rejoined after a 5-minute gap), Pillar 3 (DNS tunneling
via Shannon-entropy information volume per subdomain per hour; the
Jensen-Shannon divergence was measured and does not separate tunnels
from benign CDN subdomains, so it stays in the evidence at zero
weight instead of in the score), and Pillar 4 (deterministic
noisy-OR fusion across the three pillars).

The fusion formula was validated against 8 labeled real-traffic
vectors (IoT-23, CTU-Normal) with tolerance <= 1e-4. A known
limitation is kept, not hidden: a benign Philips HUE bulb's strict
periodic polling and a 21.9h session score it above three real C2
hosts. No weight or threshold was tuned to mask this; it is
documented in the architecture docs instead.

Also fixes real bugs found along the way: ingest_dir's partition
count summed file names instead of distinct dates, DuckDB errors
were counted as bad rows, /api/alerts always returned an empty list
regardless of the last analysis, and the dashboard still claimed
every pillar was unimplemented.

Restores four design corrections that were missing from
docs/architecture.md (KL to Jensen-Shannon, the persistent-session
detector, the JA4 licensing boundary, and deterministic reduction
order), and catalogs the public datasets used for validation
(IoT-23, CTU-Normal, Mendeley DTQBC) with their licenses and SHA-256
checksums under research/validation/.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAyr8d7HuAdUGB6aA5xmDD

README.pt-BR.md

@@ -8,11 +8,11 @@
 
 ---
 
-**Estado: esqueleto pré-alfa.** A estrutura do projeto, a documentação, o CI e
-os stubs que compilam existem. Os quatro pilares matemáticos de detecção, o
-parser real de logs Zeek, o armazenamento DuckDB e o motor de alertas estão
-**em desenvolvimento** e ainda não são distribuídos. Nada nesta página deve ser
-lido como promessa de que a detecção já funciona.
+**Estado: pré-lançamento (versão inicial).** A estrutura do projeto, a documentação,
+o CI, a ingestão de `conn.log` e `dns.log` do Zeek, o armazenamento analítico DuckDB/Parquet
+e as versões iniciais dos pilares 1 a 4 estão implementados e validados contra
+tráfego público. Ingestão contínua automática e persistência de alertas entre reinícios
+estão planejadas para os próximos lançamentos.
 
 O Acauã é um motor de caça a ameaças em rede construído em torno de evidência
 determinística, não de um modelo opaco. O objetivo é responder não só "isto
@@ -37,30 +37,26 @@ produziram esta pontuação".
 
 | Área | Estado |
 |---|---|
-| Workspace Rust e stubs da CLI | ✅ compila |
-| API Axum com rotas de health, status, alertas e análise | ✅ stub |
-| Dashboard web embutido | ✅ shell da UI, servido pelo daemon |
+| Workspace Rust e CLI (`acaua`) | ✅ funcional |
+| API Axum com rotas de health, status, alertas e análise | ✅ funcional |
+| Dashboard web embutido | ✅ UI servida pelo daemon |
 | Documentação e workflows de CI/release | ✅ |
 | Imagem Docker multi-arch e deployment com Compose | ✅ |
 | Armazenamento analítico DuckDB | ✅ biblioteca oficial pré-compilada linkada |
-| Quatro pilares de detecção | 🚧 em desenvolvimento |
-| Parser de logs Zeek | 🚧 stub |
-| Evidência e pontuação de alertas | 🚧 stub |
+| Quatro pilares de detecção (P1–P4) | ✅ versão inicial |
+| Parser de logs Zeek (`conn.log`, `dns.log`) | ✅ funcional |
+| Evidência e pontuação de alertas | ✅ JSON determinístico + fusão noisy-OR |
 | Releases publicadas | ❌ nenhuma ainda |
 
 ## Os quatro pilares
 
-Todos os quatro estão **em desenvolvimento**. O roadmap os mantém como trabalho
-futuro, não como recurso implementado.
+Todos os quatro pilares estão implementados em sua **versão inicial (v1)** e validados contra fixtures sintéticas e capturas públicas:
 
-1. **Beaconing:** periodicidade sobre timestamps de eventos com periodograma de
-   Rayleigh/Schuster, e Lomb–Scargle generalizado só onde existe um `y` real.
-2. **Sessões persistentes:** conexões longas que nunca produzem um `Δt` curto e
-   ficariam invisíveis para um detector de beaconing.
-3. **Anomalias de protocolo:** features determinísticas sobre logs de protocolo
-   do Zeek, incluindo sinais de identidade e movimento lateral.
-4. **Fusão de evidências:** combinação limitada e simétrica das pontuações dos
-   pilares, com um registro de evidência reproduzível por alerta.
+1. **Beaconing (Pilar 1 v1.2):** periodicidade sobre timestamps de eventos com periodograma de
+   Rayleigh/Schuster limitado ao intervalo observado, portão de significância por regularidade e exclusões de infraestrutura.
+2. **Sessões persistentes (Pilar 2 v1.0):** conexões TCP longas encadeadas através de timeouts de inatividade do Zeek (gap de até 3600s sem novo SYN), score logarítmico de persistência e rastreamento de PCR e tentativas falhas.
+3. **Anomalias de protocolo (Pilar 3 v1.0):** capacidade determinística de informação (entropia de Shannon $\times$ caracteres de subdomínios únicos por hora UTC) em consultas DNS para detectar tunelamento.
+4. **Fusão de evidências (Pilar 4 v1.0):** combinação noisy-OR ponderada por host ($w_1=w_2=w_3=0.75$) com evidência determinística em JSON e ordenação de prioridade.
 
 As decisões de projeto por trás desses pilares, incluindo as seis correções ao
 blueprint original, estão em **[docs/pt-BR/arquitetura.md](docs/pt-BR/arquitetura.md)**.