Close WAL gap in CheckpointScope::All to prevent clone failures after WAL cleanup

[udnay]

Title: Close WAL gap in CheckpointScope::All to prevent clone failures after WAL cleanup

Summary

• After CheckpointScope::All flushes, advance replay_after_wal_id to next_wal_sst_id - 1 so the checkpoint doesn't reference WAL SSTs that may be cleaned up externally
• Restore the explicit NotFound path assertion in clone_should_fail_when_wal_store_is_not_provided that was lost during Allow clone to copy WAL SSTs from a separate WAL store slatedb/slatedb#1458
• Add tests for WAL gap closure, WAL replay on clones, and cloning after external WAL cleanup

Problem

When a DB opens, fence_writers writes an empty WAL SST directly to the object store. This advances next_wal_sst_id (via replay_memtable) but not replay_after_wal_id, creating a gap of 1. After a CheckpointScope::All flush, if the memtable is already empty, flush_memtables has nothing to freeze or flush, so replay_after_wal_id never catches up.

This becomes a problem when the WAL store is cleaned up externally after a full flush — for example, a shard split where the parent is flushed to L0, the local WAL disk is wiped, and a clone is created from the checkpoint. copy_wal_ssts tries to copy the fencing WAL that no longer exists and crashes with NotFound.

Why slatedb#1458 was not sufficient

slatedb#1458 added the ability to copy WAL SSTs from a separate parent WAL store during cloning. This correctly handles the transport — reading WALs from one store and writing them to another. But it doesn't address the case where the WAL SSTs are gone entirely. The manifest still references them (the gap between replay_after_wal_id and next_wal_sst_id), so
copy_wal_ssts still tries to copy files that don't exist. The fix needs to be upstream of the copy: the checkpoint itself should not reference WAL SSTs that are redundant after a full flush.

Test plan

• test_checkpoint_scope_all_closes_wal_gap — verifies replay_after_wal_id == next_wal_sst_id - 1 after full flush
• test_checkpoint_wal_replay_needed_without_full_flush — verifies Durable scope preserves the WAL gap
• clone_replays_wal_and_continues_writing — clone replays parent WALs, writes new data, flushes, close/reopen, all data survives
• clone_succeeds_after_parent_wal_cleanup — full flush, delete WAL files, clone, verify data
• clone_should_fail_when_wal_store_is_not_provided — wrong WAL store still errors with specific NotFound path (restored from main)

[udnay]

This change is part of the following stack:

• Close WAL gap in CheckpointScope::All to prevent clone failures after WAL cleanup #5 ◀

_{Change managed by git-spice.}

[kirinrastogi]

Could we switch to upstream with this change? https://github.com/slatedb/slatedb/pull/1473/changes