fix: restore 30-minute timeout for Bazel builds (#19609)

I think raising it to 45 minutes in
https://github.com/openai/codex/pull/19578 was a mistake for the reasons
explained in the comments in the code. Instead, we attempt to defend
against timeouts by increasing the number of shards in
`app-server-all-test` so that a "true failure" that gets run 3x should
not take as much wall clock time.

.github/workflows/bazel.yml

@@ -17,11 +17,14 @@ concurrency:
   cancel-in-progress: ${{ github.ref_name != 'main' }}
 jobs:
   test:
-    # Ideally, this would be only 30 minutes, but a no-cache-hit Windows build
-    # seems to trip this limit and starting over is painful when it happens.
+    # Even though a no-cache-hit Windows build seems to exceed the 30-minute
+    # limit on occasion, the more common reason for exceeding the limit is a
+    # true test failure in a rust_test() marked "flaky" that gets run 3x.
+    # In that case, extra time generally does not give us more signal.
+    #
     # Ultimately we need true distributed builds (e.g.,
     # https://www.buildbuddy.io/docs/rbe-setup/) to speed things up.
-    timeout-minutes: 45
+    timeout-minutes: 30
     strategy:
       fail-fast: false
       matrix:

codex-rs/app-server/BUILD.bazel

@@ -5,7 +5,13 @@ codex_rust_crate(
     crate_name = "codex_app_server",
     integration_test_timeout = "long",
     test_shard_counts = {
-        "app-server-all-test": 8,
+        # Note app-server-all-test has a large number of integration tests, so
+        # even a single shard can be quite slow. When there is a legitimate
+        # test failure in a shard, it will still get run 3x in total, which
+        # can cause us to exhaust our CI timeout if the shard happens to run
+        # long. Using a higher shard count for app-server-all-test should help
+        # mitigate this risk.
+        "app-server-all-test": 16,
         "app-server-unit-tests": 8,
     },
     test_tags = ["no-sandbox"],