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/docs/architecture.md

@@ -50,7 +50,7 @@ lib/
 │   ├─ radar/     RadarSource + Dpc/Arpa/Mock implementations + models
 │   └─ alerts/    AlertSource + ArpaCap implementation
 ├─ features/    one folder per screen or coherent UI area
-│   ├─ map/ timeline/ alerts/ sources/
+│   ├─ map/ timeline/ places/ settings/ alerts/ sources/
 └─ l10n/        app_it.arb (template)
 ```
 

Nuvolari/docs/privacy.md

@@ -15,16 +15,58 @@ neither of which carries a user identity.
 
 ## Location
 
-The device may ask for location permission to centre the map. When it does:
+The device position is used to centre the map and, once the worker publishes
+station data, to pick the nearest measuring station. It is optional throughout.
 
-- **Prominent disclosure** is shown before the system permission dialog, stating what
-  the location is used for, as Google Play requires.
-- The permission is optional. Declining leaves the app fully usable: the map opens on
-  the region centre from the region config.
-- The coordinates stay on the device. They are used to position the map and nothing
-  else, and are never sent to our backend.
+### Coarse only, and enforced
 
-There is no forecast provider, so no coordinates leave the device for one.
+The app declares **`ACCESS_COARSE_LOCATION` and nothing else**. Stations are kilometres
+apart and the map is looked at, not navigated by, so street-level precision would buy
+nothing and cost a more invasive permission.
+
+This takes active enforcement. The `geolocator` plugin declares
+`ACCESS_FINE_LOCATION` in its own manifest, and the merger pulls it into ours. Left
+alone the system dialog offers "Precise", Play Services nags about Location Accuracy,
+and the Data safety form has to declare precise location — all for accuracy the app
+never asks for. The app manifest therefore removes it explicitly:
+
+```xml
+<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
+                 tools:node="remove"/>
+```
+
+Verified on a device: the system dialog reads "access this device's **approximate**
+location" and offers no Precise option. **Do not add the fine permission back** without
+a feature that genuinely needs it and a Data safety update to match.
+
+### No Play Services in the path
+
+Location requests use the platform `LocationManager`
+(`AndroidSettings(forceLocationManager: true)`) rather than the Google Play Services
+fused provider. The fused provider prompts "your device will need to use Location
+Accuracy", and declining it yields **no fix at all** — an absurd outcome for an app
+that only ever wanted an approximate one. It also means location works on devices
+without Play Services.
+
+### The permission flow
+
+- A **prominent disclosure** is shown before the system dialog, as Google Play requires,
+  stating what is used, why, and that it stays on the device. The same text is repeated
+  in Settings so someone who already answered can still read it.
+- Declining leaves the app fully usable: the map opens on the region centre and places
+  are chosen by hand.
+- The coordinates never leave the device.
+
+## Saved places
+
+A saved place — a name and a point — is the closest thing this app has to a home
+address. It is stored in `SharedPreferences` **on the device only**, under a versioned
+key, and is never uploaded, backed up to our servers or shared. There is no account to
+attach it to and no server that would accept it.
+
+Places are what the rain notifications will eventually key off, and that must not change
+where the data lives: the device will subscribe to the topic for the cell containing the
+place, so the correspondence between a person and a place stays on their phone.
 
 ## Rain notifications without a server-side location
 
@@ -44,6 +86,8 @@ simpler and it would destroy the property.
 Radar frames are cached in memory while the app runs. The cache holds published weather
 imagery only — no personal data — and does not outlive the process.
 
+Saved places are the only thing written to persistent storage, and only locally.
+
 ## What each third party receives
 
 | Party | What it receives | Why |

Nuvolari/docs/roadmap.md

@@ -6,8 +6,9 @@ emulator** — twice now that step has caught defects the tests did not.
 
 Legend: ✅ done · 🔨 in progress · ⛔ blocked on something the project owner must supply
 
-> **Scope**: radar on a map, official alerts, rain notifications. Forecasts, lightning,
-> a home-screen widget and advertising are all out — see CLAUDE.md.
+> **Scope**: radar on a map, saved places, ground-station observations, official alerts,
+> rain notifications. Forecasts, lightning, a home-screen widget and advertising are all
+> out — see CLAUDE.md.
 
 ---
 
@@ -77,7 +78,33 @@ and a disk layer belongs with the network adapter, where it would save a real re
 
 ---
 
-## M4 — Backend worker ⛔
+## M4 — Saved places and device location ✅
+
+A named point the user keeps, used to frame the map and — once notifications exist — to
+anchor them. Stored in `SharedPreferences` on the device and nowhere else.
+
+**Done and verified on the emulator.** The prominent disclosure appears before the
+system dialog, the permission is optional throughout, places survive an app restart and
+a reinstall, and tapping one moves the map onto it.
+
+Running it caught three defects the tests could not:
+
+- `geolocator` injects `ACCESS_FINE_LOCATION` into the merged manifest, so the system
+  dialog offered "Precise" despite the app declaring only coarse. Removed with
+  `tools:node="remove"`; the dialog now reads "approximate location" and offers no
+  choice.
+- The Play Services fused provider prompts about Location Accuracy, and declining it
+  yields no fix at all. Switched to the platform `LocationManager`, which also drops the
+  Play Services dependency.
+- `MapLibreMap` leaves `cameraPosition` null unless `trackCameraPosition` is set, so
+  "save the map centre" silently saved the region default instead of what the user was
+  looking at.
+
+A unit test also caught an id collision: ids came straight from the microsecond clock,
+so two places saved in the same microsecond shared an id and rename, remove and the
+duplicate check all acted on the wrong one.
+
+## M5 — Backend worker ⛔
 
 The critical path. Until this exists, `DpcRadarSource` has nothing to read and the app
 can only show demo frames.
@@ -86,8 +113,14 @@ can only show demo frames.
 reproject to EPSG:3857 — the source CRS is read from each file, never assumed),
 `palette` (dBZ colormap, legend exported into the manifest), `render` (RGBA PNG,
 transparent below threshold), `manifest`, and a `publisher/` with `LocalPublisher` and
-`S3Publisher`. Also fetches the ARPA CAP bulletin and publishes `alerts.json`, so the
-app never polls ARPA directly.
+`S3Publisher`. Also publishes, so the app never polls ARPA directly:
+
+- `alerts.json` from the ARPA CAP bulletin;
+- `stations.json` from the ARPA realtime API — rain accumulations
+  (1/3/6/12/24 h) and 72 hours of hourly temperature for the 374 stations, joined to
+  their coordinates from `/pie_anag`. The feed lags about 4.5 hours, so every reading
+  carries its own timestamp and the UI must present it as an observation, never as the
+  current conditions.
 
 WebSocket trigger on `wss://radar-wss.protezionecivile.it`, with a 5-minute cron as
 fallback.
@@ -99,7 +132,7 @@ precipitation on the emulator.
 **Blocked on (publishing only):** VPS / object storage endpoint and credentials.
 Development proceeds against `LocalPublisher` and a LAN `python -m http.server`.
 
-## M5 — Official alerts
+## M6 — Official alerts
 
 `ArpaCapAlertSource` reading `alerts.json` from our CDN. Zones `Piem-A`…`Piem-M` with
 levels shown **verbatim** and a link to the official bulletin next to every one.
@@ -112,7 +145,7 @@ bulletin reports "not assessed".
 **Accepts when:** the eleven zones render with the levels the live feed carries, the
 captured fixture parses, and every alert view links the official bulletin.
 
-## M6 — Rain notifications ⛔
+## M7 — Rain notifications ⛔
 
 FCM topics per geographic cell, subscribed **from the device**, so no user location ever
 reaches a server. The worker publishes per-cell rain state.
@@ -122,7 +155,7 @@ produces a notification on the emulator.
 
 **Blocked on:** Firebase project and `google-services.json`.
 
-## M7 — Play Store release preparation ⛔
+## M8 — Play Store release preparation ⛔
 
 Signing config reading `key.properties`, release AAB, target API 36, privacy policy,
 store listing copy, Data safety declaration, prominent disclosure for location.
@@ -138,9 +171,9 @@ location leaving the device.
 
 | Needed for | Item |
 |---|---|
-| M4 | VPS / object storage endpoint and credentials |
-| M6 | Firebase project and `google-services.json` |
-| M7 | Play Console account and upload keystore |
+| M5 | VPS / object storage endpoint and credentials |
+| M7 | Firebase project and `google-services.json` |
+| M8 | Play Console account and upload keystore |
 | ARPA radar adapter | The email to `info.meteo@arpa.piemonte.it` asking for the real-time access link **and the reuse licence**. Free of charge is not a licence, and without stated terms the frames cannot be republished. |
 
 Nothing is needed for the base map: OpenFreeMap requires no key and no account.