#10636: fix: setTimeout integer overflow causing server crash

Fixes #10626 Prevents server crashes caused by setTimeout integer overflow on low-memory instances (AWS a1.large, 4GB RAM, ARM64). ## Problem `NO_TIMEOUT_MS` was set to 30 days (2,592,000,000 ms), exceeding Node.js 32-bit limit (2,147,483,647 ms). This caused `TimeoutOverflowWarning` with silent fallback to 1ms, leading to rapid retry loops and memory exhaustion. ## Changes - Add `MAX_SAFE_TIMEOUT_MS` constant and `clampTimeout()` helper in `src/agents/timeout.ts` - Add defensive clamp in `src/gateway/call.ts` ## Testing - [x] `pnpm build` passes - [x] Tested locally ## AI Disclosure - [x] AI-assisted (Claude/Gemini) - [x] Lightly tested - [x] I understand what the code does <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> - Introduces a `MAX_SAFE_TIMEOUT_MS` constant plus a `clampTimeout()` helper to ensure timeouts stay within Node’s 32-bit `setTimeout` limit. - Updates agent timeout resolution to use a safe “no timeout” sentinel value and to clamp computed values. - Adds a defensive timeout clamp in the gateway client call path to prevent `TimeoutOverflowWarning` and runaway retry loops on large timeouts. <h3>Confidence Score: 4/5</h3> - This PR is largely safe to merge, with one correctness/perf concern around a per-call dynamic import in a hot path. - The timeout clamping logic addresses a real Node.js limit and is applied consistently in resolveAgentTimeoutMs and callGateway. The main issue is that `callGateway` now awaits a dynamic import each call, which is unnecessary overhead and could affect high-frequency callers; switching to a static import would remove that risk. - src/gateway/call.ts <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->