db/storage: reclaim the log once a checkpoint covers it

The point of a lagging checkpoint: a record whose effect the data file already
holds is redundant, so the log can go back to just its header. Without this the
log only grows and every open pays for every write ever made.

Ordering, which is the whole safety argument: publish the watermark, *then*
truncate. The other way round, a crash between them leaves the records gone from
the log and absent from any image. A failed truncation is a warning rather than
an error -- it costs space and replay time, and loses nothing, so it must not
fail a checkpoint that already succeeded.

Also wires checkpointing up, which nothing did before. `note_checkpoint` arms it
when the log passes a threshold, and the write epilogue and the TTL monitor both
claim it -- outside any collection lock, for the same reason compaction runs
there: it takes the log lock. The threshold is separate from the compaction one
on purpose: compaction is about the garbage share of the data, a checkpoint is
about how much replay an open would otherwise do.

--

Two things the tests taught me.

The first version measured the log before the checkpoint and found 16 bytes --
just the header. Appends buffer in the log's open block and only a commit seals
and writes it, so there was nothing on disk to shrink. The test commits first
now, and says why.

And the "no valid watermark" warning fired for every young database, which is
its normal state before the first checkpoint. It now distinguishes a watermark
that was *written and cannot be read* from one that was never written -- warning
about the ordinary case is how people learn to ignore the warning that matters.

Mutation-checked, red: skipping the truncation. Not covered, and the test says so:
moving the truncation before the publish, whose failure mode is a crash landing
between the two. That needs process-level crash injection, which an in-process
test cannot express.

src/commands.zig

@@ -188,6 +188,18 @@ pub fn dispatch(ctx: *Context, msg: *wire.Message, reply: *wire.Reply) !void {
         // The write is durable by now, so a compaction failure is a maintenance
         // problem and not the client's. Report it and hand the request back
         // rather than turning an applied write into an error the client retries.
+        // A checkpoint reclaims the log, so an open stops paying for every write
+        // ever made. Runs here, with no lock held, for the same reason
+        // compaction does: it takes the log lock and must not do that while
+        // holding a collection lock.
+        if (ctx.engine.take_checkpoint()) {
+            ctx.engine.checkpoint() catch |err| {
+                // Durability is unaffected -- the log still holds everything.
+                // The cost is a slower next open, which is not the client's
+                // problem, so report and carry on.
+                std.debug.print("multiforadb: checkpoint failed: {s}\n", .{@errorName(err)});
+            };
+        }
         if (ctx.engine.take_compact()) {
             ctx.engine.compact() catch |err| {
                 std.debug.print("multiforadb: compaction failed: {s}\n", .{@errorName(err)});