🪲 BUG-#1: Fix RpcClient pending requests leak

[FernandoCelmer]

Description

• src/core-client/core-client.ts: Extracted ProcessHandle interface from CoreProcess to decouple RpcClient from the concrete process implementation. Added rejectPending() private method that settles all in-flight requests with a JSON-RPC -32000 error. Hooked it into exit and spawnError event handlers, and replaced the silent pending.clear() in dispose().
• test/core-client.test.ts: Added 4 unit tests using a FakeProcess (lightweight EventEmitter stub) covering: process exit mid-flight, spawn failure, dispose, and normal response resolution.

Motivation and Context

Closes #1

RpcClient.request() stored promise resolvers in a pending map and only resolved them when a matching JSON-RPC response arrived. If the child process exited or failed to spawn, those promises hung forever — callers (sendPrompt, askAside, etc.) would block indefinitely with no way to recover.

Types of changes

• Bug fix (change that fixes an issue)
• New feature (change which adds functionality)
• Documentation

Checklist

• I have performed a self-review of my own code
• I have added tests that prove my fix is effective or that my feature works
• I have updated the CHANGELOG
• I have updated the documentation accordingly

[FernandoCelmer]

Follow-up commit: the original tests spawned a real node -e ... child process to exercise RpcClient, and that made npm test hang indefinitely — a real child process handle keeps Node's own event loop alive until the process actually terminates, independent of whether the JS-level promise already resolved. Refactored RpcClient to accept an optional ProcessHandle (defaults to a real CoreProcess, unchanged behavior in production) so tests can inject a plain EventEmitter-based fake instead. npm test now finishes in ~330ms.

[FernandoCelmer]

🔍 Code Review

Overall this is a solid, well-scoped fix with good test coverage. The ProcessHandle interface abstraction is a clean design that makes the code properly testable without spawning real processes. Two follow-up suggestions below around edge cases in rejectPending.

Code issues found: 2

#	Severity	Comment
1	[Suggestion]	pending.clear() after resolve() risks dropping re-entrant requests
2	[Suggestion]	post-exit request() calls hang forever — no dead guard