Bug Report: Monitor tool notifications misrouted when called by sub-agent

What happened?

When a sub-agent (launched via the Agent tool) calls the Monitor tool, the monitor's event notifications (stdout/stderr lines, completion notices) are delivered to the main agent instead of the sub-agent that started the monitor. The sub-agent only receives the initial "Monitor started" tool result and never sees any subsequent stream events, making the monitor effectively useless for sub-agents.

Meanwhile, the main agent receives unexpected monitor notifications from monitors it did not start, which can disrupt its reasoning context.

What did you expect to happen?

When a sub-agent calls the Monitor tool, the streaming event notifications should be delivered to the sub-agent that initiated the monitor, so it can process the monitored output and make decisions based on it. The main agent should not receive notifications from monitors started by sub-agents.

Client information

$ qwen /about
# paste output here

Anything else we need to know?

This was discovered by testing sub-agent monitor calls in both foreground and background modes. In both cases, all <task-notification> events were routed to the main agent, not the calling sub-agent.

The root cause is that MonitorRegistry is a singleton on the Config class, shared via prototype chain between parent and sub-agent configs. The notificationCallback is only set by the main agent's UI layer, and sub-agents never set their own callback. As a result, all monitor events flow through the single callback to the main agent's notification queue.

For comparison, BackgroundTaskRegistry correctly handles this scenario with foreground/background gating — foreground sub-agent completion notifications are suppressed (results flow through normal tool-result channel), while background sub-agent notifications are intentionally sent to the parent. MonitorRegistry lacks any equivalent agent-scoping mechanism.

Possible fix directions:

1. Add Monitor to EXCLUDED_TOOLS_FOR_SUBAGENTS so sub-agents cannot call it at all (simplest, but limits sub-agent capabilities)
2. Give each sub-agent its own notification routing so monitor events reach the calling agent (more complex but preserves functionality)