Get the pictures right and stop reusing stale answers

Three things you could see on dev1.

Pictures were "roughly right" rather than right, because a coordinate search
only knows what was photographed within 300 m. Wikidata's P18 is one picture
somebody chose to represent that exact object - "Zurletzteninstanz.jpg" for the
restaurant, not a statue down the road - so it now leads, then the Commons
category, and geosearch is the last resort it should always have been. Small
venues carry a wikidata tag far more often than a Commons category, so this is
also what reaches the places the other sources miss.

Descriptions stayed on Wikipedia after the switch to Wikivoyage because the
week-long result cache predates it. It carries a format version now; a release
that changes the shape or the sources invalidates its own entries instead of
serving last week's for another six days.

Ratings and opening hours were being fetched from Google and then dropped on the
floor - the fact list only looked at OpenStreetMap tags. Both are shown now,
whichever provider supplied them.

Also: the column follows a place opened from the map, not only one picked from
search. A POI tap arrives as prefillCoords and never touched the selection, so
the column kept showing the previously added place.

Pictures are a tight three-column grid and only the picture in play is credited
in full, on one line. Crediting all of them at two lines each drowned the
column, and the licence attaches to the one that gets used - whose credit also
stays visible in the inspector after saving.

The request carries the place record the dialog already fetched, so the server
skips a details lookup it was making in parallel with the client's own. That
lookup was measured at 12.8 s for a large OSM relation.

shared/src/maps/maps.schema.ts

@@ -147,6 +147,7 @@ export type PlaceDescription = z.infer<typeof placeDescriptionSchema>;
  * `kind` is translated client-side; `value` is provider data and stays as-is.
  */
 export const placeFactKindSchema = z.enum([
+  'rating',
   'cuisine',
   'openingHours',
   'menu',
@@ -176,6 +177,16 @@ export const mapsPlaceEnrichmentRequestSchema = z.object({
   /** Used to resolve a Wikipedia article when the place carries no wiki tag. */
   name: z.string().min(1).max(300),
   lang: z.string().max(35).optional(),
+  /**
+   * The place record the client already holds from picking the search result.
+   *
+   * Enrichment needs the same OSM tags that lookup returned, and fetching them
+   * again is not cheap: an Overpass lookup for a large relation was measured at
+   * 12.8 seconds. Passing them along turns a second slow round trip into none.
+   * Only the tags are read, and the wiki tag is re-validated before use, so a
+   * doctored payload can at worst mislead the user who sent it.
+   */
+  details: z.record(z.string(), z.unknown()).optional(),
 });
 export type MapsPlaceEnrichmentRequest = z.infer<typeof mapsPlaceEnrichmentRequestSchema>;