B02 SQLite append-only audit log + hash chain in verifier

[pulkitpareek18]

Task 3 of today. Implements the verifier-local audit log from the design doc §4.3.

Why a second audit log

We already have `audit_events` in the API's Postgres. The verifier-local SQLite log is defense in depth: if Postgres ever gets rewritten by an attacker with DB-level access, an auditor can reconcile against the verifier's tamper-evident replica. Hash-chained, append-only-at-SQL-trigger-level, written on a separate disk volume from Postgres.

Architecture

• `verifier/src/audit-log.ts` — better-sqlite3, WAL mode, schema with 14 columns including `sequence` (monotonic), `prev_hash`, `entry_hash`. SQL triggers refuse UPDATE + DELETE.
• Hash chain per design doc §5: `entry_hash = sha256(canonical(row excl entry_hash) || prev_hash)`. Canonical = JSON with sorted keys, no whitespace.
• Genesis row at first init: `sequence=0, tenant_id='system', prev_hash=0×64`.
• Proofs + public signals are hashed on storage, never persisted in full (security-policy §10).

Server wiring

• `POST /verify` now appends a row per request; `verifierAuditId` in the response points at a durable record (was throwaway uuid before).
• `GET /health` includes an `audit` block: `{ rowCount, nextSequence, lastEntryHashPrefix }`.
• `GET /audit/stats` — same data, dedicated endpoint.
• `GET /audit/verify-chain` — walks the full chain, reports `ok | firstBadSequence | firstBadReason`. O(N), for periodic ops.

Infrastructure

• Dockerfile: alpine doesn't ship better-sqlite3 prebuilds for arm64-musl, so the verifier-production stage `apk add`s python3+make+g++ as a virtual `.build-deps` package, runs npm install (which triggers node-gyp build), then `apk del .build-deps` to keep the runtime image slim (~150MB saved).
• `/app/data` created with non-root ownership at image build time so the user can write the SQLite file.
• New `verifier-audit-data` named volume in compose, mounted at `/app/data` on the verifier container.

Local end-to-end smoke (against the rebuilt image)

```
=== /health ===
{"status":"ok","vkeyAvailable":true,"audit":{"rowCount":1,"nextSequence":1,...}}

=== 3 verifications ===
v=false audit=d29b2a57-9e2 lat=577ms # first: includes snarkjs init
v=false audit=cd0f4461-335 lat=25ms
v=false audit=0d906949-61f lat=22ms

=== /audit/stats ===
{"rowCount":4,"nextSequence":4,"lastEntryHashPrefix":"887ff050d115af7c"}

=== /audit/verify-chain ===
{"ok":true,"rowsChecked":4}

=== DELETE attempt ===
OK: verifier_events is append-only — DELETE refused
=== UPDATE attempt ===
OK: verifier_events is append-only — UPDATE refused
```

Tests

• `verifier/tests/audit-log.test.ts` (16 new): genesis row shape, appendEvent + chain advancement, 5-event chain stays unbroken, tamper detection (drops the trigger, mutates a row, verifyChain catches it on entry_hash mismatch AND on prev_hash mismatch), SQL trigger refusal, getStats, hashPayload determinism.
• `verifier/tests/server.test.ts` (23 existing) updated to `initAuditLog(':memory:')` in beforeAll.
• 39 verifier tests pass (23 + 16). Backend 228 unchanged.

Out of scope (next)

• Plumb `tenantId` + `environment` from API → verifier in the `verifyViaService` call (currently the verifier records `'unspecified'`). One-line change in `src/services/zkp.ts`.
• Surface `verifierAuditId` into the API's `audit_events` row metadata so the two logs cross-reference.
• Nightly backup of `verifier-audit-data` volume.

🤖 Generated with Claude Code