map/responseMap: type-predicate selection for Google addressComponents (child of #94) #116

Gap found by the #94 capstone ("GAP #4" in lead-finder.test.ts).

Problem. The epic proof map bullet is "addressComponents → {city, suburb, state, country}." Google returns addressComponents as an ARRAY of {longText, types:[…]}, where you pick the element whose types[] includes locality / administrative_area_level_1 / country. The map step's extract and the connector responseMap both use getPath, whose grammar (dotted + numeric index + arr[].{…}) has no "find the element where types[] contains X" predicate. So extract:{city:"addressComponents.locality"} resolves to null against real Google data — geo fields don't populate declaratively.

Evidence. getPath(googleAddressComponents,"locality") === undefined; map(..., extract:{city:"addressComponents.locality"}) → city:null. Asserted as GAP #4. (The recipe does this in code via geoFromComponents — comps.find(x => x.types.includes(t)).)

Consequence. The reference JSON keeps the extract block (correct intent) but geo fields stay null until this lands; the live worker still does it in code.

Proposed fix (pick one):

1. Extend the getPath/responseMap grammar with a type-predicate array filter, e.g. addressComponents[types~=locality].longText (select element whose types array contains the token, then sub-path).
2. A small map option fromComponents that takes {typeKey:"types", valueKey:"longText", pick:{city:"locality",state:"administrative_area_level_1",country:"country",suburb:"sublocality"}} — a declarative version of geoFromComponents.

Option 1 is the most general and also helps any "array of typed components" API. Part of #94.