fix(server): discover Windows ports without PowerShell [WIP]

[UtkarshUsername]

What Changed

• add a windowsListeners command to the existing native resource-monitor sidecar
• read IPv4 and IPv6 TCP listeners with Windows GetExtendedTcpTable
• use the native listener snapshot for preview port discovery
• retain a map-once PowerShell fallback with exponential backoff when the sidecar is unavailable
• cover native discovery, fallback failures, cooldown behavior, and protocol handling with focused tests

Depends on #9476. The local branches are managed as a gh-stack chain. GitHub cannot base this upstream PR directly on the parent branch because both contribution branches live in a fork.

Why

Windows preview discovery currently launches Get-NetTCPConnection every three seconds and performs one Get-Process call per listener. On affected systems, those WMI-backed commands overlap, consume sustained CPU, and spin the fans.

The resource-monitor sidecar already ships with the server and owns native process telemetry. Reading the Windows TCP table there removes PowerShell from the normal path without adding another native dependency. The fallback remains available for environments without a compatible sidecar, but failures no longer create an unbounded retry loop.

Closes #5900.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Verification:

• vp test run apps/server/src/preview/PortScanner.test.ts apps/server/src/resourceTelemetry/NativeTelemetryClient.test.ts apps/server/src/diagnostics/ProcessDiagnostics.test.ts apps/server/src/resourceTelemetry/Model.test.ts apps/server/src/resourceTelemetry/ResourceTelemetry.test.ts apps/server/src/resourceTelemetry/ResourceTelemetryHistory.test.ts (62 passed)
• git diff --check

Model: GPT-5 | Harness: Codex / T3 Code

Note

Discover Windows ports and process tables via native sidecar instead of PowerShell

• Adds processTable and windowsListeners commands to the resource-monitor sidecar, reading TCP listeners via the Windows IP Helper API (GetExtendedTcpTable) and process relationships via the sysinfo crate, bypassing PowerShell entirely on the happy path
• Bumps RESOURCE_MONITOR_PROTOCOL_VERSION from 2 to 4 across contracts, the sidecar, and all test fixtures; adds typed request/response schemas for both new commands
• NativeTelemetryClient (NativeTelemetryClient.ts) exposes processTable and windowsListeners effects with 5-second response timeouts and pending-request cleanup on sidecar failure
• PortScanner (PortScanner.ts) now tries native listener discovery first, falling back to the PowerShell probe with capped exponential backoff (3s → 60s) and retaining the last successful fallback snapshot across failed retries
• TerminalManager (Manager.ts) prefers native process-table snapshots for subprocess inspection, falls back to spawned PowerShell data on failure, and backs off polling delay (doubling up to 60s) after consecutive snapshot failures
• Risk: protocol version jump from 2 to 4 means an older sidecar binary paired with a newer server (or vice versa) will reject handshakes; the RESOURCE_MONITOR_PROTOCOL_VERSION constant in resourceTelemetry.ts and main.rs must ship together. Windows fallback path still shells out to PowerShell when native discovery fails, so PowerShell removal is partial.

^{Macroscope summarized 674d991. (Automatic summaries will resume when PR exits draft mode or review begins).}

[t3dotgg]

Note

🤖 GPT-6 Astra (preview) responding on behalf of Theo

This note is part of an automated cleanup pass.

Carryover from #6254 at 920f8251d9: retain listener-to-PID/process-name mapping and the interrupted-scan case, where a later scan must run normally. Check degraded discovery with a previously found non-common port so it does not disappear only because fallback probes common ports. Its old single-flight test does not start the first fork before awaiting the second scan, so do not copy that test unchanged. Keep terminal ownership fresh when reusing listener data.

[SunkenInTime]

Tested this draft on Windows x64 in a dedicated worktree at c27fa4e1b131311051d609a344ca2c6f5e7262a2, including its incremental diff over #9476. Requesting changes for finding 1.

1. P2: reject failed or truncated PowerShell results before replacing the snapshot. At PortScanner.ts:547, stdout is parsed without checking result.code or result.stdoutTruncated. ProcessRunner returns nonzero exits as ordinary results, and this call uses truncation mode. Starting with a valid listener, an exit-1/empty-stdout result clears it and resets cooldown; the next immediate scan launches PowerShell again. Truncated output has the same problem. Two added regression cases fail: expected one retained listener and two total launches, received zero listeners and three launches. Validate exit status and completeness before parsing, route invalid results through the existing failure branch, and add both cases to the suite.

2. Separate existing Windows issue: rapid terminal restart followed by close crashes with Signals not supported on windows. The adapter, node-pty dependency, and explicit signal path predate these PRs; a standalone reproduction also fails. This needs a separate close-before-ready fix and is not the reason for requesting changes here.

3. Nonblocking cleanup: add direct response, timeout, interruption, and restart coverage for the new client command. Consider sharing its repeated request lifecycle machinery. Also consider matching #9476's backoff when native discovery fails but PowerShell succeeds: this scanner resets failures and resumes PowerShell every scan, which may be an intentional compatibility choice.

Existing validation passes: bun fmt, bun lint, bun typecheck, 144 focused TypeScript tests, 18 Rust tests, Rust formatting, and release build. Native probes verified IPv4/IPv6 ownership and closed-listener removal; real PTY/RPC checks verified Node activity, terminal ownership, Ctrl+C, and port removal. The two additional failure cases above fail. This was not an installer, sustained CPU, or separate #9520 frontend acceptance run.

Blueprint review and design report includes numbered findings, the required correction, architecture, and full evidence. Download the evidence bundle and regression cases.