gwt-read pares: empty page on one query pauses the source and voids the batch #237

Problem

gwt-read pares treats an HTTP 200 page with no readable answer as a wall (STOP_FOR['empty'] in gwt_reader.py): the search exits as a wall and the gate hears a hit, so every lane on that source pauses for 20 minutes. PARES sends that empty page often, and in bursts. Most of the time it isn't a block: the same query, or the known-hit control, answers normally on the next try.

What we saw in one night of catalogue searches, batches of 25, with a known-hit control before and after each batch (gwt-read 1.2.0):

• One very common name pair (say «Ana López») gave the empty page on 3 of 3 tries, hours apart. Each time the batch's before-control had passed.
• Another common pair («Carmen Ruiz», say) gave it once, and on the retry returned more than 9,000 results.
• Rare names gave it too, and so did the known-hit control itself, once.
• Every empty page paused the whole source. The rest of that batch exited paused and its after-control came back paused, so all 25 rows were void. One batch failed three tries in a row this way. Over about 7 hours, 3 of 8 batches survived.

So one row can cost a whole batch, plus 20 minutes for every other lane that shares the gate.

Proposal

Keep the empty page from counting as a wall until it is shown to be one:

1. When a search gets an empty page, check it once with the source's known-hit control, at the gate's normal spacing.
2. If the control answers, the problem is that one query, not the site. Give the query its own outcome, e.g. unreadable with a new exit code. Store nothing for it, and send the gate nothing (or a soft note that slows the pace one step and never pauses).
3. If the control is empty too, it is a real wall: hit, as now.
4. Optional: if the same query hits the empty page again on a later run, report it as one the source can't answer, so the lane narrows it (place or date words) instead of retrying it as it is.

A lane can then log that row as unreadable or partial and carry on with the batch, and the before and after controls still prove the rest of the batch.