fix(frontend): pin the test timezone so date assertions are deterministic

[berardifra]

Description

frontend/tests/components/chat/ChatSessionList.test.jsx fails on any contributor machine whose
timezone is not UTC. The test feeds a UTC instant and asserts the UTC-rendered string:

{ id: 1, created_at: "2026-06-11T14:02:00Z", ... }
expect(screen.getByText("2026-06-11 14:02")).toBeInTheDocument();

while the component renders in local time (src/components/chat/ChatSessionList.jsx:86):

{format(new Date(session.created_at), "yyyy-MM-dd HH:mm")}

date-fns-tz's format uses the runtime timezone, so on Europe/Rome (UTC+2 in June) the row shows
2026-06-11 16:02 and the lookup fails. CI runs in UTC, which is why this was never caught there.

The component's behaviour is correct — analysts want local time. The defect is that the suite does
not pin a timezone, so it silently depends on the machine's own.

Fix

One line in jest.config.js:

process.env.TZ = "UTC";

It is set at config-module level rather than in setupFilesAfterEnv, so it is exported to the worker
processes before their Date is initialised — setting it after the environment is installed is too
late to be reliable.

Verification

On a Europe/Rome host:

• before: npx jest tests/components/chat/ChatSessionList.test.jsx fails; TZ=UTC npx jest … passes.
• after: passes without TZ=UTC in the environment.
• full suite after the change: 492/493. The single remaining failure
  (UserEventModal › advanced fields) reproduces identically without this change, so it is
  pre-existing and unrelated to the timezone.

No behaviour change: this only affects the test runner's environment.

Refs #3896

Type of change

• Bug fix (non-breaking change which fixes an issue).

Checklist

• I have read and understood the rules about how to Contribute to this project
• The pull request is for the branch develop
• Linters gave 0 errors.
• All tests (new and old) gave 0 errors locally (see Verification above).
• GUI modified — N/A (test-runner configuration only; no rendered output changes).
• I will address any DeepSource / Django Doctors alerts raised on the PR.
• I will address raised Copilot issues.