test(daemon): the OS process lookup tests pass on a loaded Windows machine (#2842)

daemon-lock-holder.test.ts > "reads a running process from the OS" failed
under load on Windows, and so did the seven CLI tests in the file that look
a process up. describeProcess gives each OS query 5 s: on a busy machine
PowerShell takes longer than that to start and run its CIM query, so the
lookup falls back to tasklist (the image name only, or nothing once tasklist
runs out too) and the command line is null. The in-process test's
toMatch(/ping/) then fails, and the CLI the other tests spawn sees a Node
holder it can't classify, keeps the lock, and says so. In production that
fallback is the intended fail-safe: an undescribed holder stays "unknown"
and its lock is kept.

The per-query budget is still 5 s unless CODEGRAPH_PROCESS_LOOKUP_TIMEOUT_MS
says otherwise, and nothing outside the tests sets it. The test file sets it
to 60 s for itself and for every CLI it spawns (an env var reaches both),
gives the lookup tests time to match (240 s per CLI run, 30 s for a killed
holder to go), and adds a Windows-only test that a lookup that runs out says
nothing, so the holder stays "unknown".

Validation (Windows, 16 logical CPUs, a 48-thread CPU burn running):
- describeProcess on a live PING.EXE: the 5 s budget answered nothing in 8
  of 8 lookups (about 11 s each); a 60 s budget read the command line in 6
  of 6 (median 12.6 s, max 13.6 s).
- The reported test alone: main 0 of 4, each "expected '' to match
  /ping/i"; this branch 2 of 2, and 6 of 6 with an earlier revision that
  passed the same 60 s budget as an argument.
- The whole file: main 3 of 11, the 8 failures being exactly the tests that
  look a process up; this branch 12 of 12, twice.
- No load: 12 of 12 in 20 s.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

src/mcp/process-identity.ts

@@ -35,11 +35,22 @@ export type LockHolderKind = 'codegraph-server' | 'other' | 'unknown';
 
 const LOOKUP_TIMEOUT_MS = 5_000;
 
+/**
+ * How long one OS query may run: 5 s, unless `CODEGRAPH_PROCESS_LOOKUP_TIMEOUT_MS`
+ * says otherwise. Tests set it: on a loaded machine PowerShell can take longer
+ * than 5 s to start, and a Windows lookup that runs out falls back to tasklist,
+ * which has no command line to show.
+ */
+function lookupTimeoutMs(): number {
+  const fromEnv = Number(process.env.CODEGRAPH_PROCESS_LOOKUP_TIMEOUT_MS);
+  return Number.isFinite(fromEnv) && fromEnv > 0 ? fromEnv : LOOKUP_TIMEOUT_MS;
+}
+
 /** Runs a short OS query and resolves its stdout, or null when it fails or times out. */
 function query(file: string, args: string[]): Promise<string | null> {
   return new Promise((resolve) => {
     try {
-      execFile(file, args, { encoding: 'utf8', timeout: LOOKUP_TIMEOUT_MS, windowsHide: true, maxBuffer: 1 << 20 },
+      execFile(file, args, { encoding: 'utf8', timeout: lookupTimeoutMs(), windowsHide: true, maxBuffer: 1 << 20 },
         (error, stdout) => resolve(error ? null : stdout));
     } catch {
       resolve(null);