[BhaveshThapar]

What

Db::checkpoint(dir) writes a complete, openable database into another directory by hard-linking the live SSTables and writing a fresh manifest naming them.

The bytes are not moved, so a checkpoint of a gigabyte costs milliseconds — and the source may go on to compact and unlink its own names, because a file's contents outlive its last link rather than its first.

• Fs gains hard_link, which refuses to link onto an existing name.
• Manifest::write_fresh writes a complete manifest into a directory that has none, and refuses one that already has.
• The MemTable is flushed on the way in, and only flushed: Db::flush would also drain every pending compaction, making the stall a function of how many SSTables happened to accumulate rather than of how much is buffered.
• The live set is read under the flush lock, so a compaction that published mid-checkpoint cannot leave a manifest naming a table nobody linked.

What turned out not to be needed

A read-only Manifest view. The live table set is already in memory under a lock the checkpoint takes anyway, so there is nothing to read the manifest for.

Tests

• a_checkpoint_shares_its_bytes_with_the_source — same inode, link count ≥ 2. It is a link, not a copy.
• a_checkpoint_survives_the_source_losing_the_names_it_linked — three rounds of rewrite-and-compact on the source, then the linked names removed, then the checkpoint opens with its original contents. The removal is direct rather than waiting for size-tiered compaction to choose that run: what a compaction does to a merged table is exactly this, and depending on a heuristic to pick the right one would make the test's coverage a function of the heuristic.
• Plus: buffered writes are included, later writes are not, a second checkpoint over the first is refused, and the source is unaffected.

All tests green, clippy --all-targets --all-features -D warnings and fmt clean.