feat(audit): daily retention prune for audit_log entries past 365d (#552)

[dolho]

Summary

Closes the gap left by SEC-001 Phase 4: the append-only audit log was protected by SQLite triggers but never pruned, so audit_log grew unbounded. Adds a daily APScheduler job that DELETEs entries older than AUDIT_LOG_RETENTION_DAYS (default 365, floored at 365 to respect the audit_log_no_delete trigger floor).

• New service: src/backend/services/audit_retention_service.py — mirrors log_archive_service shape, runs at 04:15 UTC daily.
• New DB op: PlatformAuditOperations.prune_audit_log() + db.prune_audit_log() facade.
• Wired into main.py lifespan start/stop.
• Architecture note added to the Background Services table.

Why the SQL deliberately uses datetime('now', ?)

Architectural invariant #16 prefers iso_cutoff() for rolling-window filters on ISO-Z TEXT columns. Here the audit_log_no_delete trigger's WHEN clause already uses datetime('now', '-365 days') — using the same form in our WHERE clause keeps the prune set and the trigger's protected set in sync, avoiding IntegrityError on day-of-cutoff boundary rows. The trigger has the underlying ISO-Z mismatch noted in invariant #16; fixing that is tracked separately to keep this PR scope-bounded.

Hash chain note

Pruning DELETEs rows, which breaks the previous_hash/entry_hash chain across the cutoff. Hash-chain verification ranges should stay inside the retention window by design. Documented in the service docstring; if hash chain is enabled and prune removes >0 rows, a structured warning is logged.

Configuration

Env var	Default	Notes
AUDIT_LOG_RETENTION_DAYS	365	Floored at 365 (trigger-bounded).
AUDIT_RETENTION_ENABLED	true	Set false to disable the scheduler.
AUDIT_RETENTION_HOUR	4	UTC hour to run; runs at :15 past.

Closes #552.

Test plan

• Unit: `pytest unit/test_audit_retention_prune.py` — 4/4 pass
  • removes only old rows
  • empty-table returns 0
  • retention_days < 365 raises before touching DB
  • boundary-row stress (mix of 1d/100d/200d/360d/366d/380d/400d/720d) — proves WHERE + trigger don't drift
• Manual: insert a synthetic 400d-old row, restart backend, wait for 04:15 UTC (or call `audit_retention_service.prune()` from a Python REPL inside the backend container), verify the row is gone and the structured log line appears.

🤖 Generated with Claude Code

[vybe]

LGTM — well-patterned background service, invariant #16 deviation correctly justified, boundary-stress test covers the trigger/WHERE alignment. Approved.