Close the statement that emptied the audit trail in silence

[davidmckayv]

Closes #138. Thanks to @beardthelion for the report, which also named the failure mode of the obvious fix and saved this from shipping as one.

What was open

audit_events is append-only, and that is enforced in the database rather than the application because the application is not the only thing that can reach the table. The enforcement was audit_events_append_only, a row-level trigger.

A row-level trigger cannot fire on TRUNCATE. So every UPDATE and DELETE was refused while TRUNCATE audit_events took every row and returned success. "We deleted the rows about the incident" had a one-statement way around it, and the statement raised nothing.

The fix

A statement-level BEFORE TRUNCATE trigger, sharing the existing function so the refusal is written once and the two cannot drift apart.

The function now answers TG_OP before it reads anything else. That ordering is the fix, not decoration: a statement trigger has no OLD record, so a guard that reaches OLD.created_at >= now() - ... compares against NULL, the IF does not fire, and control falls through to RETURN OLD and the truncate proceeds. That path is open exactly while a retention sweep has the window set — the one state a happy-path test does not check.

Retention is unaffected. Retention deletes: it names a window and removes what is older than it, so the rows about last night survive by being newer. TRUNCATE cannot name a window, so it is refused outright.

Proof

Against a real database, before the migration:

(fail) the whole table cannot be truncated
Expected: true   Received: false

258 audit rows before, 258 after — because the test rolls back either way (see below).

After the migration, by hand as the bootstrap superuser, with the retention window set to the value that opens the fail-open path:

begin;
select set_config('openbot.audit_retention_days', '30', true);
truncate table audit_events;

ERROR:  Audit events are append-only
CONTEXT:  PL/pgSQL function prevent_audit_event_mutation() line 7 at RAISE

Full retention suite: 10 pass. drizzle-kit check: clean.

About the tests

Both new tests run their truncate inside a transaction that always throws, so it always rolls back.

That is not tidiness. If this regresses, a committed truncate in the suite would destroy the audit trail of whatever database it is pointed at, and the run that discovers the bug must not also be the run that demonstrates how bad it is. A truncate that goes through leaves the sentinel on the cause chain instead of the refusal, so the assertion fails with the table still whole. Verified above: it failed, and every row was still there.

Still out of scope

Running the application as a non-owner role with INSERT and SELECT only. Without it an owner can still DROP TRIGGER, so this closes the one-statement path rather than making the guarantee absolute. Worth its own conversation, as the issue says.