fix: stabilize reply and supervisor routing

[ThanhNT29Jacky]

Summary

• make explicit reply selectors take priority over ambient turn context
• remove answered asks from the idle-delivery queue so they cannot trigger a stale follow-up turn
• let pi-subagents own contact_supervisor when its native supervisor channel is available
• make the broker integration harness and relative-path fixture portable on Windows

Root cause

ReplyTracker.resolveReplyTarget() checked currentTurnContext before an explicit to, so a reply could be sent to the wrong pending sender. Separately, answering an ask cleared ReplyTracker but left the same ask in pendingIdleMessages, allowing it to be delivered later.

Since pi-subagents 0.33.0, delegated children can receive a native supervisor channel identified by PI_SUBAGENT_SUPERVISOR_CHANNEL_DIR. pi-intercom still registered its broker-backed contact_supervisor first, preventing the native, parent-session-scoped implementation from registering.

The Windows test runner also could not spawn the npx command shim directly, and one path fixture assumed POSIX absolute-path behavior.

Behavior after this change

• precedence is replyTo -> to -> current turn -> single pending ask
• every successful/stale dismissal removes the ask from both reply tracking and idle delivery
• pi-intercom keeps the regular intercom tool, but leaves contact_supervisor to the native channel when that capability signal is present; the existing broker-backed fallback remains unchanged otherwise
• integration brokers launch through process.execPath and the already-resolved tsx CLI on every platform

Validation

Windows 11, Node 22.20.0:

npm test
# tests 93
# pass 91
# fail 0
# skipped 2

The two skips are the existing Unix permission tests. I also loaded this branch alongside pi-subagents 0.34.0 and verified the final tool set is intercom from pi-intercom plus native contact_supervisor, with no duplicate registration.

git diff --check passes.