Add locations as a common leaf support entity

[horia141]

Add locations as a reusable leaf support entity in common, following the contacts/tags pattern. Each supported entity has at most one location.

Model

• LocationDomain trunk under the workspace
• Location leaf with optional name, address line, country (ISO 3166-1 alpha-2), and GPS coordinates
• Constructor requires at least one field; if name is omitted it is derived from address, country, or GPS
• LocationLink attaches one location_ref_id (nullable) to an owner; many entities can reuse the same location
• Allowed owners: todo, calendar events (in-day and full-days), habit, chore, big plan, vacation, doc, smart list item, person

Operations

• Typical CRUD: create, load, find, update, archive, remove
• location-search matches existing workspace locations and returns external resolver candidates
• location-link-upsert assigns a single existing location ref id to an owner (or clears it)
• Archive/remove of a location unlinks it from all location links
• Archive/remove of an owner entity archives/removes its location link

Location resolver

Mirrors the search blend (ADR 0008). WEBAPI_LOCATION_RESOLVER selects the backend:

Blend	Behavior
noop	Returns no candidates (dev default)
google-maps	Places Autocomplete (New) plus Place Details for address, country, and GPS

Candidates carry name, address_line, country, gps, source, and source_id (Google place_id). GOOGLE_MAPS_API_KEY is required when the blend is google-maps. Find stays list-all; search is a dedicated non-transactional use case so Google HTTP is not held in a unit of work.

WebUI Maps widgets (when google-maps is on)

Same pattern as Google auth: the blend flag is exposed on GlobalPropertiesContext. A browser Maps key from src/webui/Config.project (GOOGLE_MAPS_API_KEY) is provided via service properties.

• Places autocomplete widget on the locations list and in LocationsEditor (selecting a place prefills create, or creates and links)
• Reusable LocationsMap plots GPS markers
• Locations trunk and vacations trunk both use that map (vacation markers come from each vacation’s linked location)

Widgets stay hidden when the blend is noop or the browser key is missing/FAKEFAKE.

Surfaces

• Core WebUI at /app/workspace/core/locations — search existing locations and suggested resolver candidates
• Single-select LocationsEditor next to tags and contacts; suggested candidates can be created and linked in one step
• Published person and doc pages show the attached location next to tags
• Public API at /v1/common/locations including POST .../search, and MCP find/search/create/load/update/archive/remove/upsert-link tools
• SQLite and Postgres migrations that backfill location_domain for existing workspaces

Tests

• Unit tests for name, address, country, GPS, constructor/update validation, query matching, NoOp, and Google Maps (httpx mocked)
• API integration tests for CRUD, search of existing locations (NoOp candidates), single location_ref_id upsert, and ACL

Client stubs were added by hand so WebUI/API/MCP can compile. Official mise run generate-client-code should still be run when a full WebAPI environment is available.