[P1] Audit-log WAL secondary buffer (crash-resilient append)

[se-jo-ma]

Problem

Per design-docs/04-architecture-operations.md:107, the audit log today is buffered before flush. "If Nautilus crashes while the buffer is full and persistence is down, audit log entries are lost. This is an accepted risk for v1. v2 may add a write-ahead log to local disk as a secondary buffer."

Distinct from session-state WAL (#22) — that one covers CLIPS fact ops; this one covers audit-log entries.

Why it matters

Audit log is the forensic record. Losing entries — even rarely — undermines compliance posture. Local-disk WAL gives crash-resilience without requiring the primary persistence path to be synchronous.

Design references

• design-docs/04-architecture-operations.md:107 — v2 mitigation

Code locations to modify

• nautilus/audit/logger.py — audit logger gains optional WAL writer; flush ordering: WAL first, then primary sink (file/Postgres/OTEL)
• nautilus/audit/__init__.py — config plumbing for WAL path
• nautilus/config/models.py — audit.wal_enabled / audit.wal_path

Acceptance

• WAL writes are durable (os.fsync per record).
• On startup, unflushed WAL entries are replayed into primary sink, then WAL is truncated.
• Latency overhead measured; default off; documented tradeoff.
• Integration test: write entry, kill broker before flush, restart, assert entry surfaces in primary sink.

Priority

P1 — audit integrity is core security promise.