Summary

Fixes #3164.

With use_faiss=False, mine_hard_negatives currently computes the full
(n_queries, n_corpus) similarity matrix before running topk:

scores = model.similarity(query_embeddings, corpus_embeddings).to(device)
scores, indices = torch.topk(scores, k=range_max + max_positives, dim=1)

For the scale mentioned in #3164 (Natural Questions, roughly 100k queries x 100k
corpus entries), that float32 matrix is about 40GB before overhead, so it can
easily exhaust 16-32GB machines. The FAISS branch already avoids this by searching
in faiss_batch_size chunks over the query axis.

This PR applies the same query-axis batching to the non-FAISS branch: compute
similarity + topk per chunk, then concatenate the per-chunk results. Since each
row is ranked independently, this preserves the mined negatives while bounding
the intermediate similarity matrix to faiss_batch_size * len(corpus).

I also generalized the faiss_batch_size docstring, added a clear ValueError
for faiss_batch_size <= 0, and made both search progress bars respect verbose.

Local peak RSS delta with all-MiniLM-L6-v2 on CPU and a synthetic corpus:

In local equivalence checks, the mined outputs matched exactly before/after for
n-tuple and triplet formats, including non-divisible chunk sizes.

Tests

Added a regression test that checks both the query-axis chunking behavior
([3, 3, 2] for faiss_batch_size=3) and output equivalence with a single-batch
run. The same test fails on the previous implementation, which calls
model.similarity once for all 8 queries.

pytest tests/util/test_hard_negatives.py -q
ruff check sentence_transformers/util/hard_negatives.py tests/util/test_hard_negatives.py