fix(docker): correct the timezone claim — UTC is the tell, not a country mismatch

The previous commit documented the clock-zone requirement as "the zone
must match the egress IP's country". Re-measuring against the deployment
case shows that is wrong.

The original inference came from reading the host's /etc/timezone
(Asia/Bangkok) and assuming the egress IP was Thai. It is not: this host
egresses from an Indonesian IP. Asia/Bangkok cleared the challenge not
because it matched a country but because it is simply not UTC, and the
two share +07, which hid the distinction.

Measured 2026-08-08, identical container, one Indonesian egress IP:

  TZ=UTC               never cleared (60s, twice)
  TZ=Asia/Jakarta      cleared in 4s
  TZ=America/New_York  cleared in 4s

America/New_York matches neither the country nor the offset nor the
hemisphere, and clears just as fast. So a UTC clock is itself the bot
signal - Cloudflare scores it as the datacenter default - and any real
zone satisfies the check.

This makes the knob considerably less fragile than documented: BROWSER_TZ
needs a plausible zone, not a geolocated one, and a deployment that moves
region does not have to keep it in sync. Comments in chrome/entrypoint.sh
and docker-compose.yml, the hard constraint in AGENTS.md, and the PR
description are corrected accordingly.

BROWSER_TZ is also documented in .env.example for the first time, which
is the file an operator actually copies - the setting decides whether
kagane works at all, and a UTC server (the common case) is exactly the
one that fails with it unset.

Re-verified against the shipped image with TZ=Asia/Jakarta:
TestSmokeKaganeImage PASS (5.00s, 56710 bytes of image/webp),
TestSmokeKaganeGet PASS (1.24s, status 200).

chrome/entrypoint.sh

@@ -1,11 +1,12 @@
 #!/bin/sh
 set -eu
 
-# Cloudflare scores a browser whose clock zone disagrees with its egress IP's
-# country as a proxy, and kagane's challenge then never clears (measured
-# 2026-08-08 from a Thai IP: identical container, UTC never cleared in 90s,
-# Asia/Bangkok cleared in 4s). So the zone has to be right, and it has to be
-# right the way Chrome reads it.
+# A UTC clock is itself the bot signal — Cloudflare treats it as the datacenter
+# default — and kagane's challenge then never clears. Measured 2026-08-08 with
+# an identical container on one Indonesian egress IP: UTC never cleared in 60s
+# (twice), while Asia/Jakarta and America/New_York both cleared in 4s. Any real
+# zone will do; the zone does not have to match the IP's country, it just must
+# not be UTC. It does have to be right the way Chrome reads it.
 #
 # TZ must carry the zone *name*. Chrome resolves the zone through ICU, which
 # takes the name from /etc/localtime's symlink target and ignores the file's