Sub-agent announce silently fails when message exceeds Telegram's character limit

Summary

When a sub-agent completes and its announce message exceeds Telegram's 4096-character limit, the delivery fails on all retries and the parent agent is never notified. The announce is silently dropped with only a [warn] log entry.

Steps to Reproduce

1. Spawn a sub-agent via sessions_spawn with a task that produces a long completion summary (e.g., a detailed QA report with tables)
2. Sub-agent completes and generates an announce message >4096 characters
3. Announce delivery fails:

[warn] Subagent announce give up (retry-limit) run=<id> child=<session> requester=<session> retries=3 endedAgo=4s

With the underlying error on each retry:

GrammyError: Call to 'sendMessage' failed! (400: Bad Request: message is too long)

4. Parent agent is never notified of the sub-agent's completion

Expected Behavior

The announce message should be delivered successfully regardless of length. Options:

• Chunked delivery: Split long messages into multiple Telegram messages (respecting the 4096-char limit)
• Truncation with link: Truncate the message with a note like "Full output available via sessions_history"
• Fallback to agent delivery: If channel delivery fails, inject the announce as a system message directly into the parent agent's session context (bypassing Telegram entirely)

Actual Behavior

All 3 retries fail with the same message is too long error (since the payload doesn't change between retries), and the announce is silently dropped. The parent agent has no idea the sub-agent finished unless it manually polls subagents list.

Impact

This breaks the core autonomous workflow: sub-agents complete work but the orchestrator never gets notified, causing tasks to stall until a human notices. The retry mechanism is also ineffective here since retrying the same oversized message will always fail.

Environment

• OpenClaw 2026.2.25
• Channel: Telegram
• Sub-agent model: minimax/minimax-m2.5 (tends to produce verbose outputs)

Suggested Fix Priority

The fallback-to-agent-delivery option seems like the most robust fix — if channel delivery fails for any reason (not just length), inject the announce directly into the parent session. This would make announces resilient to channel-specific limitations.

Chunked delivery would be a nice-to-have on top of that for channels with message size limits.