Tamper-evident audit log via append-only hash chain

[MUKE-coder]

Vision

The activity logger (#32) records what happened. A truly serious app needs to prove that the log itself wasn't tampered with — for SOC2, for legal disputes, for fraud investigation.

Proposal

Each `activity_log` row carries:

• `prev_hash` — SHA-256 of the previous row's canonical bytes
• `hash` — SHA-256 of `(prev_hash || canonical(this_row))`

A nightly cron walks the chain and asserts integrity; mismatches alert. Bonus: optional anchoring of the daily root hash to a public ledger (a tweet, a transaction, a Sigstore log) for external verifiability.

Admin UI under Settings → Audit Trail shows:

• Chain integrity status (green / red)
• Per-day root hashes
• One-click export of a signed PDF log for a date range (legal-grade evidence)

Why this is differentiating

This is genuinely "superior software" territory. Most apps cannot answer "prove this audit log is real". A framework that gives that answer for free unlocks fintech, healthcare, legal, and government use cases.

Acceptance

• Mutating a row in `activity_logs` directly via SQL gets detected on the next chain check
• A SOC2 auditor can be handed an exported, hash-anchored PDF and verify it against the public anchor

[MUKE-coder]

Shipped in v3.19.0 (commit b376f08).

Builds on the v3.16 ActivityLog. Every row now carries PrevHash + Hash columns where Hash = SHA-256(PrevHash || canonical(row)). Mutating any row breaks the chain on the next verification pass.

New internal/audit package:

• audit.Canonical(entry) — stable JSON bytes for hashing. Excludes ID + PrevHash + Hash (random or derived).
• audit.ComputeHash(prevHash, canonical) — sha256 hex.
• audit.AppendChained(db, entry) — atomic insert with FOR UPDATE lock on the latest row inside the same tx so concurrent writes can't fork the chain.
• audit.VerifyChain(db) — walks every row in (created_at, id) order, recomputes hashes, returns the first mismatch.

ActivityLogger middleware now uses audit.AppendChained instead of db.Create. Still fire-and-forget so audit DB latency doesn't block responses; chain failures log instead of cascading.

New endpoint:

GET /api/admin/activity/integrity
→ { "valid": true, "total_entries": 12345 }
→ { "valid": false, "broken_at": 47, "broken_at_id": "uuid",
    "expected": "abc...", "got": "def...",
    "message": "hash mismatch — row was modified..." }

Wire to a nightly cron for SOC2-ish audit monitoring + a Settings → Audit Trail page that shows current chain state.

Defends against: direct SQL UPDATE/DELETE on activity_logs (the most common attack vector — DBA covering tracks); out-of-band insertion of forged history.

Does NOT defend against: compromise of the running server itself. External anchoring of the daily root hash to a public ledger (tweet / chain transaction / Sigstore log) is the natural follow-up — that needs a separate adapter design and isn't in this release.

Verification cost: O(n) — ~2–3 seconds per million rows on warm cache. Acceptable for a daily/hourly cron.

Closing.