Add saved places and optional device location

A saved place is a named point the user keeps: it frames the map now, and once
the worker publishes station data it is what the nearest-station readings and,
later, the rain notifications will hang off. Free points rather than stations,
because people think in terms of home and work, not in terms of which weather
station happens to represent them.

Everything stays on the device. Places live in SharedPreferences under a
versioned key, and there is no account to attach them to and no server that
would accept them. That is what keeps the Data safety declaration able to say
no location is collected, and it must survive the notification work: the device
will subscribe to the topic for the cell containing a place, so the link
between a person and a place never leaves their phone.

Location is coarse only, and that took enforcing. geolocator declares
ACCESS_FINE_LOCATION in its own manifest and the merger pulls it in, so the
system dialog offered "Precise" despite the app asking for nothing of the sort;
the manifest now removes it with tools:node="remove", and the dialog reads
"approximate location" with no choice offered. Requests also go through the
platform LocationManager rather than the Play Services fused provider, which
prompts about Location Accuracy and, when declined, returns no fix at all —
an absurd outcome for an app that only ever wanted an approximate one, and one
that also tied location to Play Services being present.

The prominent disclosure comes before the system dialog, as Play requires, and
is repeated in Settings so someone who already answered can still read what the
permission is for. Declining leaves the app fully usable.

Two more defects found by running it and by a test:

- MapLibreMap leaves cameraPosition null unless trackCameraPosition is set, so
  "save the map centre" silently saved the region default rather than what the
  user was looking at.
- Place ids came straight from the microsecond clock, so two places saved in
  the same microsecond shared an id and rename, remove and the duplicate-name
  check all acted on the wrong one. A test caught it on a fast machine.

Saving refuses points outside the region rather than accepting them: a place in
Rome would look like it worked and then show nothing forever.

Also corrects CLAUDE.md, which still said ARPA states no licence, and records
the ARPA realtime API there with the property that governs how it may be used —
it lags about 4.5 hours, so it is an observation archive and must never sit
next to 5-minute radar looking current.

Verified: analyze clean, 158 tests passing, and on the emulator the disclosure
precedes the system dialog, the dialog asks only for approximate location, a
place survives restart and reinstall, and tapping one moves the map onto it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Nuvolari/CLAUDE.md

@@ -10,6 +10,10 @@ regions via configuration.
 
 In scope:
 - Animated precipitation radar over an OpenStreetMap base map
+- Saved places and optional device location, used to frame the map and later to anchor
+  notifications
+- Ground-station rain accumulations and 72-hour temperature from the ARPA realtime API,
+  published through the worker
 - ARPA Piemonte official alert bulletin (XML-CAP), republished verbatim
 - "Rain incoming" notifications by geographic cell
 
@@ -28,6 +32,10 @@ grounds that there are no ads today.
 - Never commit secrets. Use .env + --dart-define; keep .gitignore updated.
 - Never poll ARPA/DPC servers directly from the app: always go through our backend/CDN.
 - Never store precise user locations server-side: rain notifications use geographic CELLS.
+- Location is COARSE only. geolocator injects ACCESS_FINE_LOCATION; the app manifest
+  removes it with `tools:node="remove"`. Do not add it back without a feature that needs
+  it and a matching Data safety update. Saved places live in SharedPreferences on the
+  device and never leave it.
 - Do not use ARPA/DPC name, logo or the word "ufficiale" in a way implying an official app.
 
 ## Architecture
@@ -45,10 +53,19 @@ grounds that there are no ads today.
   "Radar-DPC"; derivative data products must stay CC BY-SA. Docs: dpc-radar.readthedocs.io.
   The rasters are on a **custom projection centred on Italy**, not EPSG:4326 or 3857, and
   their GeoKeys are internally inconsistent — read the CRS from each file, never hardcode it.
-- Radar (future): ARPA Piemonte (HDF5 ODIM, 5-minute volumes). The data is free, but the
-  real-time access link **must be requested by email** at info.meteo@arpa.piemonte.it, and
-  ARPA states no licence — only that the data is free of charge. Both the request and the
-  licence question are the project owner's to resolve. Adapter stays a disabled stub.
+- Radar (future): ARPA Piemonte (HDF5 ODIM, 5-minute volumes). The real-time access link
+  **must be requested by email** at info.meteo@arpa.piemonte.it — that request is the
+  project owner's to make. Adapter stays a disabled stub until it exists.
+- Ground stations: ARPA realtime API, https://utility.arpa.piemonte.it/api_realtime —
+  no key, no registration. `/pie_anag` gives 374 stations with coordinates (286 with a
+  rain gauge); `/data_pie` gives hourly `cum_rain_1h/3h/6h/12h/24h`, temperature, wind,
+  snow and hydrometric level for the last 3 days. **It lags ~4.5 hours** — an observation
+  archive, not a live feed, and it must never be shown as current next to 5-minute radar.
+  Fetched by the worker, never by the app.
+- ARPA licence: CC BY 4.0 per https://www.arpa.piemonte.it/note-legali, commercial use
+  permitted, credit "Fonte: Arpa Piemonte - www.arpa.piemonte.it". Both REST APIs link
+  that notice from their OpenAPI description. The radar page does not repeat it, so ask
+  ARPA to confirm it covers the radar volumes in the same email.
 - Alerts: ARPA Piemonte XML-CAP bulletin at
   https://www.arpa.piemonte.it/export/xmlcap/allerta.xml — reproduce alert levels WITHOUT
   reinterpreting; link the official channel. Six level values, not four: VERDE, GIALLO,