fix(sourcehunt): reserve a per-band minimum when cutting large-repo ranker candidates

[tsunoda-kazuya]

Summary

• Add RankerConfig.large_repo_band_min (default 0, opt-in) and large_repo_bands (default 4).
• Partition candidates into priority-quantile bands and reserve band_min from each before filling the remaining large_repo_llm_file_limit slots by the existing sort key.
• Log a warning and fall back to the current head cut when band_min * bands > limit.
• band_min = 0 (default) reproduces the historical head-cut behaviour byte-for-byte.

Problem

On repositories above large_repo_file_threshold, _select_llm_candidates keeps the head of a single global ordering. A file whose heuristic priority sits in a lower band never reaches the LLM reranker even when it is the only file in its band. --target-file covers the case where the target is already known; blind hunts still depend on this cut.

Fix

• New helper _reserve_band_minimum partitions the sorted candidate list into large_repo_bands priority-quantile bands, takes band_min from each band in sort order, and fills the rest globally.
• Fast paths preserve exact head-cut behaviour when band_min = 0, when there is only one band, when all priorities are equal, or when the input is empty.
• Overflow (band_min * bands > limit) logs a warning naming the parameters and returns the plain head cut.

Validation

• uv run --frozen --extra dev pytest -q tests/test_sourcehunt_ranker.py — 42 passed; new regressions: band reservation keeps a lone low-band file, band_min=0 matches head cut, overflow warns and falls back, empty input.
• uv run --frozen --extra dev ruff check clearwing/sourcehunt/ranker.py tests/test_sourcehunt_ranker.py
• git diff --check

Backward compatibility

Default large_repo_band_min = 0 reproduces the previous selection byte-for-byte. Behaviour changes only when a user opts in with band_min >= 1. The rerank budget (large_repo_llm_file_limit) is unchanged in either case.

Independent of the other 4 PRs in this batch; trivial rebase if any lands first.