[FEATURE] Monitor tool event notifications should support configurable content length (currently hard-truncated at ~400 chars)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The Monitor tool truncates event notifications at approximately 400 characters, appending ...(truncated) to the content. This truncation is applied to what Claude receives in <task-notification> tags — not just the terminal display.

This makes Monitor impractical for streaming structured events (e.g., JSON payloads, log entries, webhook bodies) where the payload regularly exceeds 400 characters. Claude cannot read the full event and must use a secondary tool (like reading a file or re-fetching the data) to get the complete content.

Reproduction

# A script that emits a single line longer than 400 characters
python3 -c "print('A' * 500)"

Start this via Monitor. The notification Claude receives will be truncated at ~400 characters with ...(truncated).

Proposed Solution

1. Add a parameter to the Monitor tool (e.g., max_event_length) to control the truncation threshold, or remove it entirely for the content delivered to Claude's context.
2. Increase the default limit — 400 characters is too low for most structured data formats (JSON, log lines, etc.).
3. At minimum, document the limit so tool authors can design around it.

Alternative Solutions

• Truncation could be applied only to the human-facing terminal display (similar to how <channel> tags deliver full content to Claude but the TUI truncates for display — see #43987).
• Monitor could write full events to the output file while truncating notifications, letting Claude Read the file for full content when needed.

Priority

Medium - Impacts specific workflows

Feature Category

Tools / Background tasks

Use Case Example

An agent monitors a WebSocket event stream via a background script. Each event is a single-line JSON object (~500-1000 chars). The agent needs to parse the full JSON to decide how to respond. With the current truncation, the JSON is cut off mid-field, making it unparseable. The agent must then call history or re-fetch the data through another channel, adding latency and complexity to what should be a real-time workflow.

Additional Context

• Related: #43987 (channel notification display truncation — different layer, same class of problem)
• Related: #45928 (Monitor tool is undocumented — truncation behavior is not mentioned anywhere)
• The Monitor tool's schema has no parameter to control this behavior
• The truncation marker ...(truncated) is not user-configurable