fix(ci): raise gtest discovery timeout for slow 32-bit Windows build

The Win32 (x86) C++ test job intermittently failed at build-time
gtest_discover_tests. llama/ggml/mtmd are linked statically into one
large jllama_test binary; on 32-bit Windows its startup plus
--gtest_list_tests enumeration sits near the default 5s discovery
timeout on shared CI runners. The same b9682 binary discovered within
5s in the #239 merge run but was killed at the 5s timeout in this run
(process still alive, empty output — a timeout, not a crash); the b9682
upgrade and 5 newly added tests nudged a marginal case over the limit.
x64, Linux and macOS finish well under the default and are unaffected.

Raise DISCOVERY_TIMEOUT to 120s (a maximum, so fast platforms still
return immediately), which keeps full C++ test coverage on x86 rather
than skipping the binary there. Verified locally: 445/445 C++ tests
still pass.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014L2dLbAtwdq7C6a2gFRsQQ

Author: claude

CMakeLists.txt

@@ -355,5 +355,14 @@ if(BUILD_TESTING)
         SERVER_VERBOSE=$<BOOL:${LLAMA_VERBOSE}>
     )
 
-    gtest_discover_tests(jllama_test)
+    # gtest_discover_tests runs the freshly built jllama_test executable at build
+    # time (POST_BUILD) to enumerate test cases. The default discovery timeout is
+    # 5s. The 32-bit Windows (Win32) build links the entire llama/ggml/server tree
+    # statically into one large binary whose startup + test enumeration sits right
+    # at that 5s boundary on shared CI runners: the same b9682 binary discovered
+    # within 5s in one run but was killed at the 5s timeout in another (empty
+    # output, process still alive — a timeout, not a crash). x64/Linux/macOS finish
+    # well under the default. Raise the budget so 32-bit discovery is not flaky;
+    # this is a maximum, so fast platforms still return immediately.
+    gtest_discover_tests(jllama_test DISCOVERY_TIMEOUT 120)
 endif()