refactor: distribute Acaua as a Docker image instead of a desktop app

Acaua is a collective SOC daemon consuming only Zeek log files, not a
single-user tool needing local hardware like its siblings. Drop the
Tauri desktop shell, installers and self-update entirely; the server
and its web dashboard ship as a container, updated by pulling a new
image tag.

Link against the official prebuilt libduckdb instead of compiling it
from source via the bundled feature, cutting image build time from
15+ minutes to about 3. Fix a real bug found along the way: as PID 1
in a container, the daemon ignored SIGTERM and was always killed
after the stop timeout; it now shuts down gracefully.

Also corrects the Pillar 1 beaconing score: the period estimate had a
harmonic alias (a perfectly periodic 4h series resolved to 600s), and
the old score formula flagged pure random traffic as suspicious
(p95 = 0.839 on Poisson noise). The new formula was validated against
300 samples per scenario.

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

docs/interface.md

@@ -2,66 +2,39 @@
 
 **English** · [Português](pt-BR/interface.md)
 
-The interface is a vanilla HTML/CSS/JS app embedded in the `acaua` binary and
-loaded by the Tauri shell. There is no frontend build step and no React/Next.js
-runtime. This page describes the `0.1.0` shell; it is not a screenshot tour,
-because the detection views have nothing real to show yet.
+The interface is a vanilla HTML/CSS/JS dashboard embedded directly into the
+`acaua` binary via `rust-embed` and served by `acaua serve`. There is no
+frontend build step and no heavy framework runtime.
 
 ## Layout
 
-- **Sidebar:** brand, navigation, connection state, version and update check.
-- **Overview:** scope notice, authorized-use notice and the four pillar cards.
-- **Analysis:** dataset path field, analyze button, refresh and raw JSON output.
-- **Alerts:** empty state explaining that the detection engine will arrive in a
-  later spec.
-- **Settings:** language and theme, stored locally.
+- **Sidebar:** brand logo, navigation, daemon connection indicator, version and update check.
+- **Overview:** monitoring scope notice, authorized-use warning and four detection pillar cards.
+- **Analysis:** dataset path entry, analyze button, refresh and raw JSON output inspection.
+- **Alerts:** list of alerts with deterministic evidence metadata.
+- **Settings:** language and theme preferences, stored in browser local storage.
 
 ## Language
 
-The source text is Portuguese. `i18n.js` applies English strings from
-`i18n-en.js` at runtime and persists the choice in `localStorage`. `Auto`
-follows the browser/system language. The check `node scripts/check-ui-i18n.mjs`
-fails when a visible Portuguese string has no English pair.
+The source text is Portuguese. `i18n.js` applies English translations from
+`i18n-en.js` at runtime and persists the selection in `localStorage`. `Auto`
+detects the browser language. The automated test `node scripts/check-ui-i18n.mjs`
+guarantees that every visible Portuguese string has an exact English pair.
 
 ## Theme
 
-`Auto`, light and dark are supported. `Auto` follows `prefers-color-scheme`. The
-choice is stored locally; no preference leaves the machine.
+Light, dark and `Auto` modes are supported. `Auto` reacts to system
+`prefers-color-scheme`. Preferences stay local; no telemetry is sent.
 
 ## Connection state
 
-The footer polls `/api/health` and shows one of:
+The interface communicates with `/api/health` and displays:
 
-- **Connecting:** the first request has not finished.
-- **Local service online:** `/api/health` answered.
-- **Service unavailable:** the request failed; the shell remains usable for settings.
-
-The Tauri shell can point at a local daemon or a remote `serve` in a future
-version. In `0.1.0` it uses the local API.
+- **Connecting:** initial connection in progress.
+- **Local service online:** daemon is responding.
+- **Service unavailable:** connection to daemon failed; interface remains accessible for offline settings.
 
 ## Analysis view
 
-`Analyze` posts the path to `/api/analyze` and prints the JSON response. The
-skeleton validates the path and returns a stub report. It does not parse Zeek
-records and does not render scores. Failures are shown as text, never as a
-silent empty state.
-
-## Alerts view
-
-The list is intentionally empty. A future alert row will show the pillar, score,
-timestamp and a link to the evidence record. The evidence must include inputs,
-intermediate values, sentinels, weights and the code version; a score alone is
-not enough.
-
-## Accessibility
-
-- Navigation uses real buttons and an `aria-label`.
-- The settings dialog uses `<dialog>` with a labelled title.
-- Status changes use text, not color alone.
-
-## Limitations
-
-- No real screenshots: the views are shells.
-- No alert detail, no charts and no dataset browser yet.
-- No authentication: the UI assumes a loopback daemon.
-- The desktop app does not self-update; it only reports an available version.
+Posting a directory path to `/api/analyze` triggers the Zeek ingestion and
+analytical detection pipeline.