Clock errors no longer stop probing; legend reads >=500ms (closes #149, closes #152)

The header's clocks start last in init, after the rounds, and an error
formatting them, as in a browser that rejects the "shortGeneric" time
zone name, leaves both clocks blank instead of stopping the page before
its first round. updateClocks moved out of init so a unit test can call
it.

The footer legend's red entry reads >=500ms, as README.md and
CONFIG.latencyColors have it. buildUI is exported so a unit test can draw
the page and check the legend against every entry of
CONFIG.latencyColors.

Model: opus-5-5

TODO.md

@@ -21,6 +21,18 @@ Run `make frontend-viewport-test` in CI as its own step; it is not part of
 
 # Completed Steps
 
+- 2026-10-18: a browser that cannot format the header's clocks still probes
+  ([#149](https://git.eeqj.de/sneak/netwatch/issues/149)). The clocks name the
+  local time zone through `Intl.DateTimeFormat`'s `shortGeneric` option, which
+  Chrome before 95, Firefox before 91 and Safari before 15.4 reject with an
+  error; it came before the first round started, so such a browser never checked
+  a target. The clocks now start last, after the rounds, and an error formatting
+  them leaves both blank. The footer's color legend reads `>=500ms` for red,
+  where it read `>500ms`, so 500 ms, which is red, is in one of its colors
+  ([#152](https://git.eeqj.de/sneak/netwatch/issues/152)). Unit tests check the
+  clocks with a working `Intl.DateTimeFormat` and with one that rejects
+  `shortGeneric`, and draw the page and check the legend against every entry of
+  `CONFIG.latencyColors`
 - 2026-10-18: from a trusted proxy, the backend takes the client address from
   the right-most `X-Forwarded-For` entry that is not in `TRUSTED_PROXIES`
   ([#144](https://git.eeqj.de/sneak/netwatch/issues/144)). It took the left-most