Place search for met_no and moon_phase (M5 part 3c, 2 of 2)

[txoof-bot]

Part of #238 (M5 part 3c, 2 of 2). Does the work of #176 (altitude for the weather), which was closed today.

What changed

The first real user of the setting helpers from #268: a place search on the settings page of met_no and moon_phase. Type a town's name above lat, press Search, and Use fills in the fields (Save keeps them).

• src/paperpi/places.py: find_places(text, language) asks Open-Meteo's place search (no key needed). It searches in the browser's language first and then in English, and lists each place once ("Den Haag" is found only in Dutch). Each request may take at most 12 s with its retry, so two fit in the 30 s limit of a search (limits.PLACE_REQUEST, PLACE_CONNECT).
• location_helper(lat, lon, altitude=None, name=None): a ready-made helper. The plugin names its settings. Each choice shows place, region, country, altitude and lat/lon, with a "See on map" link (OpenStreetMap). The page credits "Search by Open-Meteo, place data from GeoNames" (CC BY 4.0).
• met_no: new optional altitude setting (whole metres, -500 to 9000), sent to met.no as &altitude=. A change of altitude counts as a new place, so the saved forecast is not used. The search fills lat, lon, altitude and place (the name is always replaced, as agreed after the demo).
• moon_phase: the search fills only lat and lon (the moon doesn't need the altitude, and the plugin shows no place name).
• Docs: both READMEs, docs/writing-plugins.md (how to use location_helper), docs/decisions/setting-helpers.md (the two languages and the time limit). The example config is made again (it now lists altitude).

About #176: its example had a sign mistake. lon = 84.31 is on the Tibetan plateau, where met.no's 4949 m is right; Atlanta is at lon = -84.31. With the search, lat, lon and altitude come from one place, so this mistake can't happen there.

Area

core (src/paperpi/places.py, limits.py), plugins/met_no, plugins/moon_phase, docs, tests.

Tests

New tests/test_places.py (fake Open-Meteo: reading answers, missing fields, two languages merged, list cut at 10, time limits, the helper's fill/show/link, Open-Meteo unreachable, one language failing, odd answers). test_met_no.py: altitude in the URL and in the saved place; the search fills altitude and place. test_moon_phase.py: the search fills only lat and lon.
Tried with the real Open-Meteo: "Addis Ababa" and "Berlin" in the moon_phase settings page; the search box is shown just before lat.

• uv run pytest passes (1556 tests)
• uv run ruff check . passes
• Hardware tests run on the Pi: not needed (no display code changed)

Review

• Review agents' findings fixed before the first push (two local reviews: code and security; tests and docs). Fixed: a place without a known altitude now empties the altitude field (before, an earlier choice's altitude stayed and would be sent for the new place); one odd place in Open-Meteo's answer is left out instead of failing the whole search; when one of the two language searches fails, the other's places are still listed; clearer docs. Left as is: a place name over 60 characters or an altitude outside -500 to 9000 shows a field error after Use (nothing is saved; no real place found that does this).

Only txoof approves and merges this PR.

🤖 Generated with Claude Code