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: