Investigate retained_log_entries semantics and evaluate removal

[JoshuaChi]

Background

retained_log_entries in SnapshotConfig shifts the snapshot's last_included
index backward by N entries before purging the Raft log. The intent is to keep
trailing log entries available for slow-follower catchup without a full snapshot.

Discovery

The current implementation has a non-obvious interaction with snapshot_threshold:

effective_trigger_interval = threshold - retained_log_entries

Because the snapshot's last_included is already retained entries behind
last_applied, the lag counter starts at retained immediately after each
snapshot — not at 0. This means:

• With threshold=50, retained=3 → snapshot every ~47 new entries (safe)
• With threshold=1, retained=1 → snapshot on every single commit (test default)

No validation or documentation enforces retained < threshold. A user setting
these values close together gets significantly more frequent snapshots than expected.

Open Questions

1. Is retained_log_entries solving the right problem?

2. Should this config be removed, replaced, or just documented + validated?

3. Can the trailing-log guarantee be handled purely by the PurgeExecutor
   (i.e., purge only up to snapshot_index - trailing_n) so that snapshot
   metadata is always accurate?

Next Steps

• Research the exact failure mode this parameter was introduced to prevent
• Benchmark snapshot frequency with different retained/threshold ratios
• Decide: remove / rename / redesign / document-only