fix: promptly reject in-flight PET RPC requests on process exit/error

[StellaHuang95]

Problem

When the PET (Python Environment Tools) locator process exits or errors, its in-flight JSON-RPC requests (configure / refresh / resolve / info) did not reject promptly. Callers waited out the full 30–60s request timeouts even though PET was already gone, stalling environment discovery and refresh.

Reproduction

1. Trigger a refresh/resolve that issues a PET RPC request.
2. Have the PET child exit (crash) or emit error while the request is in flight.
3. Observe the request stays pending for its full 30–60s timeout instead of rejecting when the process dies.

Root cause

NativePythonFinderImpl.start() piped PET's stdout into a PassThrough (readable) with end: false, and the child exit/error handlers only flipped flags. Because readable was never ended, StreamMessageReader never saw EOF, the JSON-RPC connection stayed open, and pending requests rejected only after their own timeouts.

A second latent bug: onClose disposed the shared startDisposables. After a restart reassigned that field, a stale old-connection close could dispose the replacement connection.

Fix

• Give each spawned child its own captured streams, JSON-RPC connection, and localDisposables. On that child's exit/error, idempotently end only those local streams so the connection closes and pending requests reject at once.
• Guard shared-state mutation (proc / exit flags) and disposal by child/connection identity, so a stale old-child event can never end streams for or dispose a replacement connection.
• Unpipe the child's stdout from the local readable before ending it, so a late buffered write cannot raise ERR_STREAM_WRITE_AFTER_END.
• Classify the resulting PendingResponseRejected rejection as a recoverable PET connection loss (not a hard rpc_error), so an exited-child crash still restarts and retries instead of failing immediately — preserving recover-on-crash behavior with prompt rejection instead of a 30–60s wait.

Tests

Deterministic fake-child / fake-RPC unit tests (nativePythonFinder.petExit.unit.test.ts):

• pending request rejects promptly on child exit
• pending request rejects promptly on child error
• duplicate error + exit is harmless (idempotent teardown)
• stale old-child exit cannot close a replacement connection
• restart produces a usable connection and resets exit state
• a current-child crash during refresh promptly restarts and the retry succeeds
• a connection loss during disposal is NOT treated as a recoverable crash
• refresh retry limit is preserved for connection-loss errors
• buffered stdout after exit does not raise a late write error or affect a replacement

Error-classifier tests cover isPetConnectionLostError and PendingResponseRejected → connection_error.

[StellaHuang95]

🔒 Automated review in progress — @StellaHuang95 is auto-reviewing this PR.

[StellaHuang95]

Warning · Non-blocking recommendation

isPetConnectionLostError now controls PET retry behavior but lives in a telemetry module, deepening the manager-to-telemetry dependency. Move this predicate to a PET/RPC domain error module and import it from both telemetry and NativePythonFinderImpl.

[verified]

[StellaHuang95]

Warning · Non-blocking recommendation

These tests repeatedly cast through unknown to invoke private lifecycle methods and inspect private state, so behavior-preserving refactors can break them. Prefer injecting or extracting a child/RPC session factory that exposes termination and connection behavior through a stable test seam.

[verified]

[StellaHuang95]

Warning · Non-blocking recommendation

The new resolve recovery path treats PendingResponseRejected as a recoverable connection loss, but the new tests cover that behavior only through refresh. Add a resolve-specific regression test so its restart behavior does not drift from refresh.