fix(expression): honour TZ when resolving the local timezone

[phenixrizen]

The bug

helper::tz() resolves the local timezone with iana_time_zone::get_timezone(), which reads the system zone from /etc/localtime and ignores the environment. A process started with TZ=UTC therefore still computes dates in the host's zone.

On Unix, TZ is the conventional override — chrono's Local, Python, and Go all honour it — and in a container that mounts the host's /etc/localtime it is the only way to pin the zone at all.

How it surfaces

test_dates_csv sets TZ=UTC itself, and that call currently does nothing. On a machine in America/Chicago:

Expression d('2023-10-15')
  Expected: "2023-10-15T00:00:00Z"
  Got:      "2023-10-15T00:00:00-05:00"

Demonstrated directly:

before:                Ok("America/Chicago")
after set_var(TZ=UTC): Ok("America/Chicago")
process env TZ =       Ok("UTC")

The suite passes only where /etc/localtime already says UTC. GitHub runners are UTC, which is why this has stayed green.

A second, latent issue

The zone is resolved once and cached in a OnceLock, so ordering decides the result. standard.csv contains date expressions too, and test_standard_csv runs in parallel — whichever date-touching test ran first seeded the cache for the rest. Setting TZ inside one test could not fix that on its own.

The change

• tz() consults TZ first, falling back to iana_time_zone and then UTC.
• Both date-touching tests pin the zone, so ordering cannot matter.
• The resolution is documented as first-use-wins, so a later test does not reintroduce the race.

Verification

On a host in America/Chicago with no TZ exported, the full suite now passes — 46 suites, previously 45 with test_dates_csv failing. Six consecutive runs of zen-expression --test isolate to check the ordering hazard is genuinely closed. Behaviour on a UTC host is unchanged.

No new dependencies; 24 lines added across two files.