Rate-limit Event Ledger writes for repeated status events

Description

Streaming sessions can send the same status event every second. Persisting every update creates unnecessary write load.

Add a local cache to each Event Ledger instance with the following behavior:

1. On a cache miss, persist the event immediately and cache it.
2. On a cache hit, replace the cached value only if the event is newer and mark the entry as pending.
3. Persist the latest pending value no more than once every 60 seconds per event key and per service instance.
4. Schedule each entry separately, using a timing wheel or similar deadline scheduler, so writes are spread across the 60-second window.
5. Use the event timestamp when persisting so an older event cannot overwrite a newer value.
6. Remove inactive entries and enforce a maximum cache size.

Acceptance criteria

• The first event for a key seen by an instance is persisted immediately.
• Repeated events for the same key produce at most one additional write every 60 seconds per instance.
• Only the newest pending event is persisted.
• Pending state is cleared only after a successful write.
• Events received during a flush are not lost.
• Out-of-order events cannot replace newer state.
• Cache hits, misses, evictions, flushes, and failures are exposed as metrics.
• Tests cover cache misses, repeated updates, concurrent updates, write failures, expiry, and multiple instances.

The 60-second limit applies per service instance. A global rate limit across all instances is not part of this change.

Start by locating the Event Ledger implementation and its existing tests, then trace the per-instance write path. Define how cache state, separate scheduling, timestamp ordering, eviction, and metrics fit together before implementing. Done means the acceptance criteria pass, including concurrent updates, failures, expiry, and multiple instances.