Define and enforce retention for Event Ledger events

Description

Event Ledger currently has no automatic retention policy. Cassandra tables do not define a default TTL, and event writes do not apply one. As a result, events remain indefinitely; legacy deletion only marks records as archived.

Define an appropriate retention period and enforce it consistently across Event Ledger event tables and write paths. Include a safe approach for cleaning up existing data outside the retention window, accounting for Cassandra tombstone and compaction impact.

Definition of Done

• Retention duration and expiry semantics are agreed upon and documented.
• TTL is enforced for all supported event tables.
• Single-event and bulk-write paths behave consistently.
• Updating an event refreshes its expiry as intended.
• Existing records outside the retention window are removed through a bounded cleanup process.
• Tests cover event expiry and update behavior.
• The change is validated in QAT before production rollout.
• Cassandra storage growth and tombstone pressure are monitored during rollout.

Resources (optional)

• migrations/cassandra/keyspaces/event_ledger/03_init_tables.up.sql
• src/control-plane-services/event-ledger/internal/db_client/cassandra/v2.go

Start by reading migrations/cassandra/keyspaces/event_ledger/03_init_tables.up.sql and src/control-plane-services/event-ledger/internal/db_client/cassandra/v2.go to map the event tables and write paths. Confirm the retention duration and expiry semantics with maintainers, then trace single-event, bulk-write, update, and cleanup behavior. Done means the stated retention, tests, bounded cleanup, QAT validation, and rollout monitoring requirements are covered.