Prevent intercom ask reply waiter race

[johnpippett]

Summary

Fixes a race where concurrent reply-waiting intercom({ action: "ask" }) tool calls can crash Pi with Error: Already waiting for a reply.

Root Cause

pi-agent-core may execute same-turn tool calls concurrently. pi-intercom uses a single replyWaiter, so concurrent ask calls need to fail cleanly before sending.

The regular intercom ask path checked replyWaiter before awaiting resolveSessionTarget(...), but did not recheck after that await. A parallel ask can install replyWaiter during that window. The later call then reaches waitForReply(...), receives an already-rejected promise, and did not attach a rejection handler immediately.

Changes

• Recheck replyWaiter after target resolution and before generating/sending the question.
• Attach replyPromise.catch(() => undefined) immediately after waitForReply(...), matching the safer supervisor-contact path.
• Add a regression test covering immediate rejection-handler attachment and the post-resolution replyWaiter guard.
• Wire the regression test into npm test.

Validation

node --test wait-for-reply-unhandled.test.mjs
# 2/2 passing

npm test
# 38/38 passing

Related issue: #29