Test the append-only guard the database actually runs

[davidmckayv]

Two findings from @beardthelion, from #138 and their PR #139. Both are real and neither was covered by the fix that merged as #148.

The immutability test described a definition nothing runs

audit.test.ts read 0000_schema.sql and asserted on the function defined there:

const migration = await readFile(new URL("../drizzle/0000_schema.sql", ...));
expect(migration).toContain("CREATE FUNCTION prevent_audit_event_mutation");

0007 replaced that function. 0012 replaced it again and added the truncate trigger. So the assertions described a definition no database has run for a while, and would have gone on passing if the live one were edited out from under them — including if a later migration dropped the truncate trigger entirely.

A mirror test pinned to one file is a test of that file, not of the deployment. It now reads the whole chain, requires both triggers, and fails if any migration drops either.

What the guard does is still proved against a real database in audit-retention.integration.test.ts. This only holds that it is installed.

The trigger's own malformed-window branch was never reached

test("keeps everything when no policy is set", ...)   // window 0, -1, NaN

That one stops in TypeScript. sweepAuditTrail returns {deleted: null} before it ever opens a connection, so it proves the caller's guard and says nothing about the trigger — which has a branch of its own for this that nothing exercised.

That is the shape where a guard reads as covered and is not, and it matters because the trigger is the only thing standing between the table and anything that does not go through the sweep. The new test sets the value the sweep would have set and then deletes directly, for "0", "-1", "" and "garbage".

Changelog

Catches it up with tonight's five fixes: the truncate hole, the declined take-the-wheel, the routing trail, the partial connector grant, and answer provenance.

The truncate entry keeps the caveat the report was careful to state — the application connects as the database owner in the shipped compose file, and an owner can still disable or drop a trigger, so this closes the one-statement path rather than making the guarantee absolute.

---

On process: #139 was open before I built #148, and I did not check. The fix that merged is the same trigger with the same TG_OP-first ordering, because the issue laid out both. Their PR covered ground mine did not, and this is that ground, credited.