Context

During the PR review of #10187 (diagnoseMcpConcurrency script), two non-blocking UX edge cases were identified.

The Problem

1. Windows ENOENT edge case: The runLsof catch block only treats error.status === 1 as a success path. Any other failure rethrows, which on Windows (lacking the lsof binary natively) surfaces as a raw ENOENT stack trace rather than a graceful failure.
2. parseLsofOutput file-path overwrite: When lsof reports a single PID holding the main database as well as -wal and -shm siblings, only the last record's file string survives on that PID's parsed object. While harmless for the current PID-deduplication logic, this causes structural imprecision if future consumers need a per-process file list.

The Architectural Reality

The script runs diagnostic probes relying on POSIX-standard commands. For cross-platform stability, gracefully handling missing binaries provides better UX. Furthermore, parsing should faithfully represent the OS state before downstream consumers drop unneeded fields.

The Fix

1. Soften the ENOENT error in runLsof into a clean log message indicating: "Platform not supported: this diagnostic requires lsof (macOS / Linux)."
2. Update parseLsofOutput to push file paths into an array rather than overwriting the string property.

Acceptance Criteria

• Windows/missing lsof execution logs a graceful fallback message instead of throwing an ENOENT stack trace.
• The parsed output object for a PID holds an array of all matched SQLite files (main, -wal, -shm) rather than just the last one.

Out of Scope

• Porting the script to use native Windows diagnostic commands (e.g., PowerShell equivalents). This remains a POSIX-centric tool.

Related

• Sibling to #10187
• Parent Epic: #10186

Handoff Retrieval Hints

• query_raw_memories(query="diagnoseMcpConcurrency Windows lsof fallback file overwrite")