v2.2.0: searches end on Google's own signal, and --deep-scan

A fresh-install test found a depth 10 search stopping at exactly 100 places. The engine was deciding a list had ended after 20 seconds without a new batch. That guess cost time when Google was already finished, and cut results short when Google was slow. The engine now reads Google's own signal instead, and the CLI gets a deeper whole-city mode.

Fixed

• Searches end on what the page asks for, not on a timer. The engine watches the result page's own batch requests. When a scroll asks Google for nothing more, the list is complete and the search ends at once. When a request is in flight, the engine waits for its answer (up to 45 seconds) instead of giving up after 10. A feed still drawing the last batch is never mistaken for the end. Live on 2026-11-01: "plumbers in Boise ID" at depth 10 went from 100 places in 30.6 s to 119 places in 22 s; "restaurants in Manhattan NY" at depth 20 returns 120 in 25 s; "dentists in Denver CO" at depth 10, 120 in 26 s.
• Google's own count still varies by about 20 places between identical runs. That is Google, not the kit.

New

• --deep-scan, the ! option (slower). Runs the city grid (3 x 3 unless --grid says otherwise), then splits every tile that came back at Google's cap of about 120 places into four sub-tiles one zoom level in, and dedupes everything on place_id. The script prints the expected time range before it starts. Live on Salt Lake City restaurants with --grid 2 --deep-scan: 239 places in 254 s, against 225 in 87 s for the plain grid. CLI only; the web UI has no deep-scan option yet.

Tests

Five new offline tests cover the scroll loop (a silent end is quick, a slow batch is awaited, slow rendering is not the end, failed batches, a too-slow batch stays bounded) and one covers --deep-scan. Engine version 2.2.0. Windows, Linux and Docker were not live-tested for this release.

Update with bash scripts/update.sh.