test(automation): widen fake codex app-server success timeout under load

Flake #5: the codex app-server / model backend tests (the success-path
`codex_app_server_*` / `fake_codex_app_server_*` cases) flaked under
parallel execution.

`fake_codex_response_timeout()` was 5s on non-Windows — the budget for the
fake codex child (a real python interpreter) to spawn and complete its
scripted turn. Under process-per-test parallelism that spawn can be
scheduled slowly enough to exceed 5s, yielding a spurious "timed out waiting
for codex app-server response".

Fix (test only): use a uniform generous 30s success-path budget (matching
the prior Windows value). Tests that deliberately exercise the timeout path
pass their own tight `Duration` (e.g. 300ms) and are unaffected.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: ScriptedAlchemy

tests/automation_runner_test/backend.rs

@@ -24,12 +24,15 @@ use crate::common::{
 
 static ENV_LOCK: Mutex<()> = Mutex::new(());
 
+/// Success-path budget for the fake codex app-server child to spawn (a real
+/// python interpreter) and complete its scripted turn. This is the upper bound
+/// the backend waits before declaring a timeout; it must be generous enough
+/// that a slow python spawn/schedule under nextest's process-per-test
+/// parallelism can never false-fire it, while still failing fast on a genuine
+/// hang. Tests that deliberately exercise the timeout path pass their own tight
+/// `Duration` (e.g. 300ms) and are unaffected by this value.
 fn fake_codex_response_timeout() -> Duration {
-    if cfg!(windows) {
-        Duration::from_secs(30)
-    } else {
-        Duration::from_secs(5)
-    }
+    Duration::from_secs(30)
 }
 
 fn fake_codex_response_timeout_secs() -> u64 {