Status bar clock: stop allocating kilobytes per second - #244

The top-bar clock is the single largest steady allocator in the OS:

- update_time called mpos.time.localtime() THREE times per firing (once
  each for hours, minutes, seconds), and the timer fires every second.
- Every localtime() call ran the full POSIX-TZ pipeline in localPTZtime:
  string splits, filter lists, two transition parses

Together that is ~4,5 KB of garbage per second on an ESP32, causing
excessive garbage collection pauses.

Three changes:

- topmenu.update_time calls localtime() once and indexes the tuple.
- localPTZtime grows a public tzoffset(timestamp, ptz) that returns
  (utcoffset, isdst, valid_from, valid_until). The offset a POSIX-TZ
  rule yields is piecewise constant in the timestamp: it changes only
  at the two DST transitions and at new year, and those instants fall
  directly out of the parse it already does. _timecalc delegates to
  it, so the branch logic exists once.
- mpos.time.localtime() caches (ptz, offset, isdst, valid_from,
  valid_until) and reuses it while valid_from <= now < valid_until.

The cached path is one time.gmtime() plus one tuple, ~224 B. The full
computation now runs about three times a year (two DST transitions and
new year), plus on boot and on timezone change. The validity interval
is exact, not a TTL heuristic: the clock is correct to the second
through DST transitions, and a backward clock jump (NTP correction)
simply misses the cache and recomputes.

Verified against uncached tztime(): 409,690 comparisons across five
zones (northern/southern DST, GMT0, angle-bracket half-hour offset,
Julian-day rule) with second-by-second sweeps around every transition
and year boundary 2025-2027, plus 1.64M randomized interval
cross-checks 2020-2035: zero mismatches.