Report how much of the band index the df cutoff skips

[r0ny123]

Refs #201 — it doesn't answer the WAND/MaxScore question, it gives you the number to answer it with.

The worry in #201 was that a fixed STORAGE_BAND_DF_CUTOFF skips a growing share of the index as the corpus grows (vocabulary follows Heaps' law, V(n) = 1412.8 · n^0.7247 here, while postings grow with the number of functions), and that nothing would ever say so. Recall at the corpus sizes I can reach is 1.000, so there's nothing to tune WAND against yet. What was missing was a way to watch the gap open. This adds one:

GET /band_df_cutoff_coverage                      # the configured cutoff
GET /band_df_cutoff_coverage?band_df_cutoff=500   # or any other
McritClient.requestBandDfCutoffCoverage()

It's a job, not something on the query path: counting skipped postings per lookup would roughly double the index work of every band lookup. The result gives, per band and in total, the band hashes and postings, how many of each are over the cutoff and the fractions, plus max_df, and it repeats the over-cutoff counts and fractions at 50, 100, 200, 500 and 1000 whatever cutoff was asked about, so two reports taken months apart compare directly. On the 7,244-sample corpus:

cutoff 200	over the cutoff	total	share
band hashes	83,235	8,538,312	0.97 %
postings	51.8 M	111.8 M	46.4 %

That split is the cutoff doing its job (stopword hashes are few and fat). The thing to watch is postings_over_cutoff_fraction moving between runs at the same cutoff; when it does, re-measure recall with benchmarks/compare_quality.py before touching the cutoff.

Each band is one $group over the (band_hash, df) index alone, a covered scan that never fetches a band document, with constant memory and no allowDiskUse. The same shape took 39.3 s for all 20 bands on that corpus (MongoDB 7.0). Under STORAGE_BAND_BUCKET_SIZE a spilled hash counts once with its bucket-0 total. A database whose df isn't trusted yet gets available: false and a message, rather than df-less posting lists counted as empty.

Two bucketing fixes came out of writing the counter:

• rebuild_band_df_index only updated an existing bucket 0, so a hash whose bucket 0 was gone while higher buckets survived kept no df anywhere — the cutoff never served it and the report couldn't count it. The rebuild now recreates bucket 0 while postings survive, as the recompute after a deletion already did.
• The recompute's upsert created bucket 0 without a function_ids array, and every lookup reads it, so the next match touching that hash died with KeyError: 'function_ids'. Both upserts create it with an empty list now, and neither creates one for a hash that has no postings left.

WAND/MaxScore isn't built: it needs posting lists sorted by function id, which the fill-order buckets aren't. docs/TUNING.md explains how to read the report; tests/testBandDfCutoffCoverage.py checks both backends give the same numbers, bucketing changes nothing, the count is index-only (no FETCH in the plan), and the repair cases. Unit and mongo suites, ruff and ty are green.