fix(place-search): bound results by distance, before truncating

[timwangmusic]

A user in San Francisco searched for a store and got Arizona. Reproduced against this service from (37.7749, -122.4194):

query	radius sent	in range	what came back
Fry's Food and Drug	8000	0 / 10	Phoenix + Tucson, 920–1212 km
Bashas	8000	0 / 10	Kingman → Tucson, 804–1199 km
Fry's Food and Drug	500	0 / 20	same 20 rows as radius=16000

Why

location+radius on legacy Text Search is a ranking bias, not a restriction — the Maps SDK says so in the field's own doc ("prominent results from outside of the search radius may be included") — and params() on that endpoint emits no restriction parameter to send instead. parseTextSearchResponse filtered on place id, geometry, dedupe and ClosedPermanently, never on distance; it didn't even receive the origin.

This was the only place-returning path in the service with neither a distance bound nor a distance sort. Both nearby paths read Redis GEORADIUS, which genuinely is bounded, and SortPlacesByDistance / utils.HaversineDist already existed here — text search just called neither.

The change

Order of operations is the fix. Truncation moves out of the parse loop to after the filter and the sort. Cutting to the limit first leaves the bound with only Google's most prominent rows — the ones that can be a thousand kilometres away — and discards local matches ranked 11th–20th. A page is at most 20 places, so parsing all of it is free.

Bias and bound are now separate numbers. Google receives a narrower bias (PlaceTextSearchBiasRadius, 8 km) than the bound the response is filtered against (PlaceTextSearchDefaultRadius, 80 km). Widening the bias to match would push local results out of the single page the filter has to work with — backwards.

80 km because a text query names a place the user may drive to. MaxSearchRadius (16 km) is the nearby cap — the Redis widening ceiling — and it fails inside one metro (SF→San Jose is ~68 km). 80 km covers a metro end to end and sits an order of magnitude under the nearest wrong-state result measured (804 km). Absent or 0 bounds at the default; no opt-out, because unbounded is the bug.

The zero-origin gate is load-bearing: (0,0) is in the Gulf of Guinea, so filtering against it would drop everything. The HTTP handler already rejects a zero location, so it only covers direct callers and the existing tests.

Also corrects the handler's doc comment, which had recorded the belief that produced this — anchoring a query biases it, it does not bound it.

Verification

go test ./iowrappers/... ./planner/... green, go vet clean, gofmt clean. Five new tests: the Arizona set drops to empty, a cross-metro result survives at 80 km but not at the nearby radius, a local match below the limit survives truncation, survivors come back nearest-first, and a zero origin or zero radius disables the bound. The eleven existing parse tests are unchanged in behaviour — only the call signature moved.

Note: bin/mintpat does not build on main (stale client.NewPAT signature). Pre-existing, verified on the base commit, untouched here.

Deploy note

This is one Gin handler on the VM all four Convex deployments share, with no staged rollback. The app-side bound (offerbee-ai/Offerbee#305) is already independent of it, so this can merge on its own schedule.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FJSjdEEbVdGZrgJqeuJja1