MARC harvest: raise show_n for title keys — a verified match can rank below the top 3

[rybesh]

Every server in sources/marc/marc_harvest.py's SERVERS list sets show_n: 3, so select_record() only ever runs verify_title against the top 3 records a title probe returns. That looks like a politeness/cost knob, but it is also a recall ceiling, and it is orthogonal to the verify thresholds: widening it grows what verify gets to judge, rather than weakening the judgement.

Evidence

From the SCAD run in #97 (2,920 non-held books still missing MARC), one of the 12 hand-recovered false negatives was not a title-variant problem at all:

• 9H7N8P5P — Carl Andre: Ausstellung vom 18 Oktober bis 15 Dezember 1968, Städtisches Museum Mönchengladbach
• SCAD's record is an exact 245 match with a matching year and the right secondary author (Cladders, Johannes)
• It ranked 4th of 7 hits

verify_title would have accepted it on the spot. It simply never saw it. The other 11 recoveries were genuine cataloguer title variants that verify legitimately rejected — this one was pure show-depth loss.

Why this likely generalizes

Z39.50 relevance ranking is weak on the exact shape of title this collection is full of: single common words and very short titles. Sampling the residual turned up Book, Green, This, Poem, Drawing, American, Climax, Alice, Distance, Sing, Journey, Handbook — several returning double-digit hit counts (one hit 31). A three-record window over 31 relevance-ranked hits from a catalogue with no useful ranking is close to arbitrary.

Nothing about this is SCAD-specific; all eleven servers run at show_n: 3.

Suggested work

1. Re-run one or more already-completed servers over their own recorded misses at a higher show_n (10 is what adjudicate_review.py uses) and count how many additional records verify. This is measurable without changing harvest behaviour — it answers "how much recall is the window costing us" before committing to anything.
2. If the yield justifies it, raise show_n for the title keytypes specifically. Identifier keys (bib, isbn) are trusted and returned first, so they gain nothing from a wider window.
3. Consider making show_n per-keytype rather than per-server, since the cost is only paid on the ambiguous probes.

Cost is a real consideration — show_n multiplies records transferred per probe, and these are shared public services we are already rate-limiting ourselves against (qsleep/bsleep). Step 1 is deliberately scoped to answer whether the yield is worth that before anything changes.

Notes

• adjudicate_review.py (added in feat(marc): add SCAD Z39.50 target; recover 475 non-held records (#84) #97) already re-queries a run's review.tsv rejects at show_n=10, so most of the harness for step 1 exists.
• It only looks at rows reading title hits failed verification. Books where every probe returned 0 hits are a different problem (not held / not catalogued / unindexable title) and are unaffected by show_n.
• Thresholds TITLE_STRONG = 0.85 / TITLE_WEAK = 0.60 should stay untouched — this issue is explicitly not about loosening verification.

Follow-up to #84 / #97.