[Story]: Audit log retention policy (180-day minimum)

## Summary
Document and implement a configurable audit-log retention policy with a 180-day minimum, matching the enterprise bar set by GitHub's audit log.

## Intent / Source of truth
180-day retention is the named competitive bar; falling short is a concrete, checkable RFP gap. Part of [Epic] SIEM-exportable audit log.

## Scope
- [ ] Retention configuration (minimum 180 days, customer-configurable longer)
- [ ] Storage/lifecycle implementation enforcing the retention window
- [ ] Published retention-policy documentation for customer security reviews

## Out of scope
- Long-term (multi-year) archival tiering (only if a customer specifically requires it later)

## Verification
An event older than the configured retention window is provably no longer queryable/exportable; documentation reviewed against the SOC 2 readiness epic's evidence requirements.

## Risk assessment
Retention that's shorter than advertised is a compliance misrepresentation risk; the enforcement mechanism must be tested, not just documented.

## AI Usage Declaration
Drafted with AI assistance during the 2026-08-13 cross-repo backlog consolidation and enterprise-readiness research. A human owns intent, verification and consequences.

Start by locating the audit-log storage, lifecycle, query, and export entry points in the repository, then read the related configuration and persistence code. Done means a configurable retention period enforces a 180-day minimum, older events are no longer queryable or exportable, and the published retention documentation matches the SOC 2 evidence requirements.

Written by the indexing model from the issue text.