milestone 27: diagnostics — operational failures land in one curated log, resolved history purgeable

PLAN.md

@@ -435,8 +435,28 @@ CREATE TABLE forward_zones (
 );
 
 CREATE TABLE settings (key TEXT PRIMARY KEY, value TEXT NOT NULL);
+
+CREATE TABLE operational_events (
+    id INTEGER PRIMARY KEY,
+    code TEXT NOT NULL,
+    subject_key TEXT NOT NULL,
+    subject_label TEXT NOT NULL,
+    severity TEXT NOT NULL CHECK (severity IN ('warning', 'error')),
+    first_seen INTEGER NOT NULL,
+    last_seen INTEGER NOT NULL,
+    occurrences INTEGER NOT NULL CHECK (occurrences > 0),
+    resolved_at INTEGER,
+    detail TEXT NOT NULL DEFAULT '',
+    CHECK (resolved_at IS NULL OR resolved_at >= first_seen)
+);
+CREATE UNIQUE INDEX idx_operational_events_active
+    ON operational_events(code, subject_key) WHERE resolved_at IS NULL;
+CREATE INDEX idx_operational_events_last_seen
+    ON operational_events(last_seen DESC);
 ```
 
+`operational_events` is the one table here that is **not** configuration. It is the diagnostics log of `src/storage/events.zig`: one row per failure episode, opened on the first failure and resolved when the same subject succeeds again. It is deliberately absent from `config_schema.table_names` and `config_schema.delete_order`, so `nxdns export` never emits it and `nxdns import` never wipes it.
+
 ### 11.3 querylog.db Schema
 
 ```sql