Fix kmermatcher memory size allocation OOM.

[bbuschkaemper]

The split memory limit doesn't account for 64-bit types, causing OOM failure.

Summary

This fixes an OOM failure in the kmermatcher on 64-bit builds on large dbs. Since kmermatcher ids are DBKeyType, the per-kmer memory footprint increases in 64-bit mode. The current split sizing could allocate the main kmer arrays almost exactly up to --split-memory-limit, leaving no room for fixed allocations, per-thread scratch buffers, allocator overhead, etc.

The calculation now:

• Computes exact main per-kmer memory including optional write buffer
• Reserves fixed memory for seqkey_to_len and per-thread kmer generation buffers
• Adds 10% headroom to remaining split budget (I added this as precaution, should we change it?)
• Prevents count-table budget underflow when fixed memory already consumes the limit

Validation

Our clustering of the Uniprac db with ca. 1B sequences crashed at the kmermatcher step. With this fix, the run completes successfully. The old split calculation selected 2 splits but sized each split too close to our 900G memory limit, causing OOM with additional allocations.

[Copilot]

Pull request overview

This PR adjusts kmermatcher split sizing to better account for 64-bit per-kmer memory footprint and fixed/per-thread allocations, reducing the likelihood of OOM on large databases when --split-memory-limit is tight.

Changes:

• Introduces saturating arithmetic and helper routines to compute split budgets with fixed-memory reservations and headroom.
• Reworks main and count-table split calculations to use a computed “available budget” instead of sizing right up to the raw memory limit.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.