Auth Audit Log Fix

Fixed

• Auth audit logging restored — Login, logout, TOTP verification, password change, password reset, and email verification events are now recorded again after RLS broke the audit trail on auth routes (bug_azq6)

Root Cause

The fastify.audit.log() helper writes to the tenant-scoped audit_log table via the connection pool. After RLS was enabled in v3.5.0, INSERT operations on auth routes failed silently because no app.current_org_id session variable is set outside the tenant middleware. Auth events were lost — no user-facing impact, but security events went unrecorded.

Resolution

• New auth_audit_log table — Global table outside RLS scope, purpose-built for security events that occur before tenant context exists. Captures event_type, user_id, email, ip_address, user_agent, and details (JSONB)
• New fastify.authAudit.log() decorator — Writes directly to auth_audit_log via the pool, mirroring the existing fastify.audit.log() pattern
• Auth routes migrated — All 12 audit calls across auth.ts, password-reset.ts, and email-verification.ts now use authAudit.log() instead of audit.log()
• Tenant-scoped audit_log table unchanged — business event audit trail remains RLS-protected

Files Changed

• db/migrations/v3.5.2-auth-audit-log.sql — Migration: table, indexes, grants
• src/server.ts — AuthAuditEntry interface, authAudit decorator
• src/routes/auth.ts — 8 audit calls migrated
• src/routes/password-reset.ts — 2 audit calls migrated
• src/routes/email-verification.ts — 2 audit calls migrated

Housekeeping

• Removed stale organisation.ts.bak file