[BUG] Flaky test: custom-tool-registry.spec.ts times out intermittently on CI

[tupe12334]

Description

The test should load tools from TypeScript files in packages/core/src/custom-tools/__tests__/custom-tool-registry.spec.ts intermittently times out after 60 seconds on CI runners.

Steps to Reproduce

1. Open a PR that triggers CI
2. The platform-unit-test job may fail with timeout
3. Re-running the failed job often makes it pass

Evidence

• PR feat: add Redis Open Source (Redis Query Engine) as alternative vector store for code indexing #10184: First CI run failed, re-run passed
• Both Ubuntu and Windows runners affected

Error Message

FAIL src/custom-tools/__tests__/custom-tool-registry.spec.ts > CustomToolRegistry > loadFromDirectory > should load tools from TypeScript files
Error: Test timed out in 60000ms.
If this is a long-running test, pass a timeout value as the last argument or configure it globally with "testTimeout".

Potential Causes

1. esbuild compilation - Transpiling multiple TypeScript fixture files
2. File I/O - Scanning directory and reading .ts files
3. CI resource variability - Slower runners may exceed the 60s timeout
4. No esbuild cache - Cold cache on CI causes slower compilation

Suggested Fixes

1. Increase timeout for this specific test (e.g., 120000ms)
2. Add esbuild caching for CI
3. Reduce number of fixture files being compiled
4. Mock esbuild in tests instead of actual compilation

Environment

• CI: GitHub Actions
• Platforms: ubuntu-latest, windows-latest
• Test framework: Vitest

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause Analysis

The flaky test should load tools from TypeScript files times out because:

1. It runs first in the loadFromDirectory describe block (using describe.sequential)
2. It triggers cold esbuild-wasm compilation for all 6 fixture files (simple.ts, invalid.ts, legacy.ts, mixed.ts, multi.ts, cached.ts)
3. Each compilation spawns a subprocess via execa
4. On slower CI runners with resource variability, this can exceed 60 seconds
5. Subsequent tests in the same block benefit from the disk cache

Proposed Fix

Increase the timeout for the first test from 60000ms to 120000ms (2 minutes)

This is the most pragmatic solution because:

• The disk caching mechanism already exists (tsCache + filesystem cache in os.tmpdir())
• The test needs real esbuild compilation to validate the tool loading functionality
• Mocking esbuild would reduce test coverage for an important integration path
• 120 seconds provides sufficient headroom for slow CI runners while still catching genuine hangs

Changes:

1. Modify packages/core/src/custom-tools/__tests__/custom-tool-registry.spec.ts line 230
2. Change }, 60000) to }, 120000)

This aligns with the first suggested fix in the issue and addresses the CI resource variability mentioned.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.