test(server): stop asserting UTC rendering with a substring that matches the date

[kstonekuan]

Summary

test_preview_stats_render_timestamps_in_utc_on_a_non_utc_host asserted "-04" not in bound_value to catch the host's -04:00 offset leaking into the stats panel. That substring also matches the day in 2026-09-04 and the month in any April date, so the test fails on the 4th of every month and through all of April no matter what the code under test does. Main is red today for that reason:

AssertionError: assert '-04' not in '2026-09-04T01:44:38.834552+00:00'

Reported independently by @akshatpatel64 on #383 and @victorwon2001 on #384, both of whom had to explain it away in their own validation runs.

Why this shape

The bounds are compared to the row timestamps and to the wall clock instead of sniffed for a substring. That removes the date collision and covers strictly more, which two mutations show:

SUMMARIZE over the bare projection (the original defect)   -> FAILED (caught)
clock shifted to host zone, '+00:00' still stamped         -> FAILED (caught)

The second one is new. The old substring check passed it, and so does a rows-to-stats comparison on its own, because rows and stats both go through select_head and shift together. The fixture stamps recorded_at as it appends, so anchoring the max bound near datetime.now(UTC) is what makes a whole-hour zone shift visible; America/New_York is 4 hours away and the window is 1 hour.

Validation

uv run ruff check, uv run ruff format --check, uv run ty check clean; uv run pytest -q 1453 passed, 6 skipped.

Checklist

• I added or updated outcome-focused tests for changed business logic.
• I updated documentation for changed behavior, flags, formats, or requirements.
• I ran uv run ruff check --fix, uv run ruff format, and uv run ty check.
• I ran the relevant pytest suite.
• I did not add recordings, generated media, credentials, private URLs, or runtime artifacts.
• I preserved stored-data compatibility or documented an explicit version change.