Reduce rust-ci-full Windows nextest timeout flakes (#23253)

## Why
Recent `rust-ci-full` failures were dominated by transient Windows
timeout clusters in process-heavy tests such as `suite::resume`,
`suite::cli_stream`, `suite::auth_env`,
`start_thread_uses_all_default_environments_from_codex_home`, and
`connect_stdio_command_initializes_json_rpc_client_on_windows`.

The goal here is to make those known flaky paths less likely to fail
full CI without relaxing the global nextest timeout policy.

## What changed
- Enable one global nextest retry with `retries = 1` so a single
transient failure can recover.
- Add a `windows_process_heavy` test group with `max-threads = 2` for
the recurring Windows subprocess/session-heavy timeout families.
- Add Windows-only slow-timeout overrides for that process-heavy group.
- Add a narrower Windows-only timeout override for
`start_thread_uses_all_default_environments_from_codex_home`, which
still exceeded the broader Windows bucket in both Windows full-CI lanes.
- Increase the `rust-ci-full` nextest job timeout from `45m` to `60m` so
Windows ARM64 still has job-level headroom after retries and targeted
per-test timeout increases.
- Keep the global `slow-timeout` unchanged at `15s`.

## Validation
Validated through `rust-ci-full` GitHub Actions reruns on this PR.

Observed improvement on the tuned Windows lanes:
- Windows x64 went from `5 timed out` to `0 timed out`.
- Windows ARM64 went from `2 timed out` to `0 timed out`.
- `start_thread_uses_all_default_environments_from_codex_home` recovered
as a flaky pass on Windows ARM64 instead of timing out.

The remaining failing tests in those runs were unrelated hard failures
outside this nextest timeout tuning.

.github/workflows/rust-ci-full.yml

@@ -524,10 +524,9 @@ jobs:
   tests:
     name: Tests — ${{ matrix.runner }} - ${{ matrix.target }}${{ matrix.remote_env == 'true' && ' (remote)' || '' }}
     runs-on: ${{ matrix.runs_on || matrix.runner }}
-    # Perhaps we can bring this back down to 30m once we finish the cutover
-    # from tui_app_server/ to tui/. Incidentally, windows-arm64 was the main
-    # offender for exceeding the timeout.
-    timeout-minutes: 45
+    # Windows ARM64 is the long pole here, and nextest retries plus targeted
+    # Windows timeout headroom need more than 45m to finish reliably.
+    timeout-minutes: 60
     defaults:
       run:
         working-directory: codex-rs

codex-rs/.config/nextest.toml

@@ -1,6 +1,7 @@
 [profile.default]
-# Do not increase, fix your test instead
+# Retry once so one transient failure does not fail full-CI outright.
 slow-timeout = { period = "15s", terminate-after = 2 }
+retries = 1
 
 [profile.default.junit]
 path = "junit.xml"
@@ -17,6 +18,9 @@ max-threads = 1
 [test-groups.windows_sandbox_legacy_sessions]
 max-threads = 1
 
+[test-groups.windows_process_heavy]
+max-threads = 2
+
 [[profile.default.overrides]]
 # Do not add new tests here
 filter = 'test(rmcp_client) | test(humanlike_typing_1000_chars_appears_live_no_placeholder)'
@@ -47,3 +51,18 @@ test-group = 'core_apply_patch_cli_integration'
 # Serialize them to avoid exhausting Windows session/global desktop resources in CI.
 filter = 'package(codex-windows-sandbox) & test(legacy_)'
 test-group = 'windows_sandbox_legacy_sessions'
+
+[[profile.default.overrides]]
+# This Codex-home startup path still exceeded the broader Windows-heavy ceiling
+# in both Windows full-CI lanes after contention was reduced.
+platform = 'cfg(windows)'
+filter = 'test(start_thread_uses_all_default_environments_from_codex_home)'
+slow-timeout = { period = "1m", terminate-after = 2 }
+
+[[profile.default.overrides]]
+# These Windows-heavy tests spawn subprocesses, session files, or JSON-RPC
+# clients and have been the dominant source of 30s full-CI timeouts.
+platform = 'cfg(windows)'
+filter = 'test(suite::resume::) | test(suite::cli_stream::) | test(suite::auth_env::) | test(start_thread_uses_all_default_environments_from_codex_home) | test(connect_stdio_command_initializes_json_rpc_client_on_windows)'
+test-group = 'windows_process_heavy'
+slow-timeout = { period = "45s", terminate-after = 2 }