fix: honor explicit k in indel search, clamp above the pigeonhole optimal

[Roman-Young]

Resolves #28. indel_search ignored the user's k and always used the derived optimal, so an explicitly-passed k was silently swapped and its k-mer table rebuilt. It now:

• Honors an explicit k when it doesn't exceed the pigeonhole optimal — reusing an existing k-mer table (e.g. one built for a mismatch run) instead of rebuilding.
• Clamps a larger k to the optimal with a warning, preserving complete recall (a k above max(2, min_len // (max_indels + 1)) drops below max_indels + 1 disjoint seeds and forfeits the guarantee).
• Derives the optimal when no k is given (unchanged).

Composes with the existing constructor guard: k > shortest query length is already rejected up front, so indel_search only clamps within the functional band.

Consistency with mismatch: _auto_k is generalized to take the edit count so the two paths share one pigeonhole formula instead of duplicating it. Indel additionally clamps a too-large explicit k (mismatch honors it as-is) — indel's completeness guarantee is a core claim, so it warns and uses the optimal rather than silently dropping recall.

Tests: 4 new cases in test_indel_search.py (in the CI matrix) — honor + table-reuse, clamp + warning, unspecified → optimal, and k > min_len rejected. Full suite green (52); 500/500 seeds agree with the brute-force oracle (match set unchanged).

[dmx2]

Thanks!