Weather: JMA area forecast on tapping a place

[TokyoDanInJapan]

Tap the rider dot or a dropped pin → a menu (Weather here / Clear pin) →
JMA's area forecast for that spot, laid out the way the JMA page lays it out.
The radar says what the rain is doing in the next hour; this says whether to
set off at all.

Keyless, like every other source in the app.

北東部                          長柄町 · 4 km
─────────────────────────────────────────
Forecast
              Today      Tomorrow    7/27
Weather        ☁          ☁          ☁
Temp          ↑35°      ↑33° ↓26°

Rain %      00-06  06-12  12-18  18-24
Today          –      –      20     20
Tomorrow      20     20      40     50
─────────────────────────────────────────
Day by day
Today     くもり時々晴れ夜のはじめ頃一時雨…
          Wind: 北の風 · Waves: １．５メートル
─────────────────────────────────────────
Week ahead
        7/28  7/29  7/30  7/31  8/1
Weather   ☁     ☁     ☁     ☀    ☀
Rain %   40    40    30    20    20
Max     31°   32°   33°   33°   33°
Min     25°   24°   25°   26°   26°
Conf.     C     C     B     B     A
─────────────────────────────────────────
Outlook / Source …

Resolving a position to a forecast

JMA keys forecasts by area code, never by coordinates, and the codes aren't
derivable from the JIS prefecture code — Hokkaido splits seven ways, Kagoshima's
mainland office is 460100, Okinawa splits four. tool/prep_forecast_areas.dart
walks JMA's own area.json (class20 → class15 → class10 → office) against the
municipality table already in the repo and bakes a 1716-row lookup. Runtime
resolution is nearest-municipality, which gets the subdivision (千葉県北東部,
not just "Chiba") — a rider in south Chiba shouldn't read Chiba city's forecast.

Verified against live JMA across four regions: Chiba → 北東部 via 長柄町 (4 km),
渋峠 → 長野北部, Sapporo → 石狩地方/札幌管区気象台, Naha → 本島中南部/沖縄気象台.

Things the data forces

• Series are identified by the fields their areas carry, not by position.
  JMA has reordered timeSeries before; inland offices omit waves entirely.
• Temperatures pair by clock time, not index. A midday issue echoes the
  day's high into the already-past 00:00 low slot, so reading positionally
  reports "high 35, low 35". A low equal to the high is dropped, not shown.
• Rain columns are fixed. JMA drops a block once passed, so derived columns
  would shuffle between morning and afternoon. A dropped block reads –, never
  0 — "no longer forecast" and "0% chance" are different claims.
• Only days with numbers are held back from the weekly table. The detailed
  block's last day is routinely wording alone, and the weekly block does carry
  its temps and rain chance; treating "mentioned above" as "covered above" threw
  them away. Caught against live data, not in review.

Icons

From JMA's 3-digit 天気コード, bucketed by leading digit (1 晴れ, 2 くもり,
3 雨, 4 雪). JMA publishes ~130 codes but no machine-readable table — there is
no telop.json, only the page's JavaScript — so the rule was checked against
live data from ten offices spread across the country: 87 of 87 periods
agreed with JMA's own wording. Four buckets on purpose, with JMA's wording
carrying what the icon drops. An absent code draws a dash rather than a guess.

Translation

English mode translates on device like closures do, except place names use
JMA's own English ("North-eastern Region", "Sapporo City"), baked into the
generated table. Machine translation is at its worst exactly where JMA is
already authoritative. A test asserts the translator is never asked for 北東部
or 長柄町, so a regression that quietly routed place names through ML Kit fails
rather than just getting worse.

The Japanese shows the moment it arrives and the English swaps in behind it —
the first translation ever can be a ~30 MB model download, and someone deciding
whether to set off shouldn't watch a spinner while the forecast is already in
hand. A failed translation degrades to Japanese, the same contract the closure
list has had. ClosureTranslator._translate becomes public translateText; the
translator instance is shared because it owns the model and the string cache.

Also

• Forecast fetches get their own AssetKind, so they group in the debug sheet.
• The rider dot's tap target grows to 44 px around an unchanged 22 px dot — it
  marks a position and a bigger dot would claim precision the fix doesn't have,
  but a 22 px target on a moving bike is not one.

Verification

flutter analyze clean, 145/145 tests (43 new), release APK builds.

Three bugs the tests caught before they shipped:

• The fetch future could fail before FutureBuilder subscribed, which Flutter
  reports as an unhandled async error — a red screen over the map in debug.
• setState as the first statement of an async method called from initState
  runs synchronously, i.e. during the build mounting that widget. Harmless
  today only by accident.
• revealInSheet needed ensureVisible: being in the tree isn't being on
  screen, so a tap aimed below the fold landed on nothing. A latent flake.