saveSnapshot_overwritesThePriorSnapshotWhole

RaftStorage.saveSnapshot's contract says it "overwrites any previously stored snapshot", and until this property no test saved two.

Overwriting is not an edge case — it is what compaction does every time it runs, so a storage that gets it wrong gets it wrong on its second snapshot and every one after. The adapter shape is the obvious one: a snapshots table with an INSERT, read back by a SELECT … LIMIT 1 with no ORDER BY … DESC, which restores the oldest baseline. That node comes back believing its log was compacted to an earlier cut than it was, so entries(snapshotIndex + 1) selects entries that were discarded and returns a log with a hole.

Every field of the second differs from the first, and the config differs in the direction that matters. The superseded snapshot carries a joint config; the surviving one carries null. So a non-null config in the result is attributable — it can only have come from the snapshot that was supposed to be gone. Written the other way round (null first, config second) a storage that merged the two records field-by-field, keeping whichever half was non-null, would pass. It cannot pass this.

The restart arms are here rather than in a property of their own because the write-through cache passes the same-handle half by construction: it serves the latest snapshot from a live field and appends rows underneath, so only the reopen sees which row the SELECT picks.