fix(chat): raise pre-token guard from 120 s to 300 s

The client-side TURN_TIMEOUT_MS was the binding constraint: turns with
slow prompt processing (no first SSE frame within 120 s of visible time)
errored with the 'stuck' copy even though nginx (300 s) and
BOR_LLM_TIMEOUT (300 s) would have let them run. Raise the guard to
300 s so the upstream timeouts are reachable, and re-pin the tests:
the unit constant pins and the fake-clock E2E timeline (295 s hidden
+ 290 s after the re-arm = 585 s: past the original 300 s deadline,
short of the re-armed 595 s deadline).

Verified: tests/unit (full, 100% pass), tests/e2e/test_hidden_tab_stream.py
and tests/e2e/test_loading_feedback.py in isolation.

tests/unit/test_frontend_hidden_tab.py

@@ -152,8 +152,8 @@ def test_real_navigation_behavior_is_unchanged() -> None:
     # The phase-48 teardown contract (real close / navigation / Stop still
     # aborts the fetch) is untouched.
     assert "turnAbort?.abort()" in js, "the abort owner still aborts the fetch"
-    assert re.search(r"export\s+const\s+TURN_TIMEOUT_MS\s*=\s*120_?000\s*;", js), (
-        "the guard constant is still 120s (owner-locked phase-17/48 value)"
+    assert re.search(r"export\s+const\s+TURN_TIMEOUT_MS\s*=\s*300_?000\s*;", js), (
+        "the guard constant is still 300s (raised from the phase-17/48 value)"
     )