Background compaction is triggered by bytes written, not dead space #53

The maintenance loop starts compaction once per checkpoint_wal_mb (256 MiB) of page writes, and each pass moves at most one segment. Across 16 benchmark runs that was exactly one pass per run. A small database that is mostly dead space can go a long time before anything happens.

It would be better to start from how much can be reclaimed:

• keep a running count of dead bytes per sealed segment (liveness() walks every tree, too slow to call often)
• compact when a segment is both mostly dead and big enough to bother
• pick segments by bytes freed per byte copied

The live ratio barely matters right now: 0.3 and 0.9 picked the same 23 segments in my runs because they were about 95% dead. Part of #47.