[Feature Request]: Improve /api/maps/search results for foreign-region queries

[kjake]

Summary

Two small, backward-compatible additions to POST /api/maps/search that improve results when callers know the rough geographic context of their query:

1. Optional locationBias (lat/lng/radius). Forwarded to Google Places Text Search as locationBias.circle. Without it, foreign-coordinate queries get biased by the API key's billing region.
2. Expose Google's types[] field in the response. Already returned by Google, currently dropped before reaching callers.

Both fields are optional / additive — the default behavior is unchanged.

Motivation

I hit both of these while building an external photo-import pipeline against my self-hosted Trek instance. The pipeline takes EXIF GPS coordinates from old iPhone photos and asks Trek to name the nearest POIs, so it can auto-create places on trips that pre-date my use of Trek (in my case, a 2011 China/Thailand trip where most photos came from a Canon point-and-shoot but a handful had iPhone 4S GPS data).

Two pain points:

• Foreign-region bias. Searches like searchPlaces("park near 22.30,114.17") (Hong Kong) returned results from my home region (US Midwest) instead of Hong Kong. Google's Text Search needs locationBias to know where the caller actually means; without it, it defaults to the billing region of the API key.
• No way to prefer attractions over generic businesses. When importing a GPS cluster, I want to prefer "Victoria Peak" (a tourist_attraction/park) over "Victoria Peak Cafe" (a restaurant named after it). Google returns this signal in types[] per result, but it's not exposed by /api/maps/search today, so my pipeline had to round-trip through place-details to filter.

Proposed shape

Request body (additions):

POST /api/maps/search
{
  "query": "park",
  "lang": "en",
  "lat": 22.30,        // optional
  "lng": 114.17,       // optional
  "radius": 5000       // optional, meters
}

Response (addition per result):

{
  "places": [
    {
      "name": "...",
      "address": "...",
      "lat": ...,
      "lng": ...,
      "types": ["park", "tourist_attraction"]   // new
    }
  ]
}

Compatibility

• Existing callers omit the new fields → identical behavior to today.
• New types: string[] is purely additive — UI that ignores it is unaffected.
• OSM/Nominatim fallback path is unchanged (it doesn't consume locationBias today).

Status

Draft PR up at #974 implementing both pieces (~35 lines across routes/maps.ts + services/mapsService.ts). Leaving it as a draft until approval via this Discussion. Happy to add integration test coverage in server/tests/integration once the direction is approved.

There's a related but more invasive idea I have — a brand-new /api/maps/nearby endpoint for the same photo-import use case — that I'll open as a separate Discussion to keep the conversations focused.