Android: a kept place-name pack never refreshes #109

Once a country's place-name pack is kept on a phone, the app never fetches it again. With the Landmarks workflow rebuilding the packs every week (#108), a kept pack falls further behind the published one each Monday, and nothing tells the reader.

What happens now

• PlacePacks.keep stores <code>.txt and <code>.json, and the JSON records the list's built stamp. PlacePacks.kept() reads that stamp back into Kept.built, but nothing compares it with the built of the current packs.json.
• In the list of countries, a kept pack can't be tapped (PlaceScreen.kt, pack.code !in kept). So the only way to get newer names is Forget, then Keep again, and nothing suggests doing it.
• Kept landmark areas already handle this. LandmarkArchive.shard compares the archive's built with the kept copy's and reads fresh shards when online. Packs have no equivalent.

Why it matters

Searching offline reads the kept packs. Searching online reads the site's name index, which the Pages workflow now redeploys after every Landmarks run. Once a pack is a few weeks old, the two can give different answers for the same name: a place added since it was kept is found online but not offline, and a place renamed or removed since is still found offline.

Things to settle

• What counts as changed. built changes for every country on every run, so comparing it would re-download all kept packs every week. Comparing each country's lines and bytes in packs.json is a cheap proxy. A per-pack hash written by build-names.mjs would be exact.
• Automatic or offered. Packs can be large: the United States is 20.4 MB gzipped, China 7.4 MB and India 6.2 MB, while Canada is 1.2 MB. Options are an "Update" button beside a stale kept pack, a refresh on Wi-Fi only, or both.
• Safe to replace. keep already writes .txt.part and renames it only after the lines and bytes match the list, so a refresh that fails leaves the old copy in place. That should be checked against a refresh that fails partway, and against the old copy being open in sources while it is replaced.
• The publish window. The workflow uploads the packs before packs.json. A phone that read the list just before a run, then fetches a pack during it, gets a pack that doesn't match the list it holds, and the line and byte check refuses it. A refresh should read the list again before it retries.

This changes the app, so it ships with the next bundle.