Bug Description

Reply tags like [[reply_to:6100]] are appearing in iMessage messages from cron announcements and subagent completions. The tags should be stripped before delivery but aren't.

Environment

• OpenClaw version: 2026.2.21-2
• Channel: iMessage
• Trigger: Cron announcements with delivery.mode = "announce"

Root Cause

File: dist/subagent-registry-Bdm_X-N1.js:69626
Function: buildCompletionDeliveryMessage()

The function uses raw params.findings.trim() without calling parseReplyDirectives() to strip reply tags:

function buildCompletionDeliveryMessage(params) {
  const findingsText = params.findings.trim();  // ← Tags not stripped here
  const hasFindings = findingsText.length > 0 && findingsText !== "(no output)";
  // ...
  return `${header}\n\n${findingsText}`;  // ← Tags included in delivery
}

Expected Behavior

Reply tags should be stripped from announcement messages before delivery to any channel (iMessage, Slack, etc.), similar to how they're stripped in other delivery paths that call parseReplyDirectives().

Actual Behavior

Messages appear in iMessage like:

[[reply_to:6100]] Got it. This is a test message.

The tags are visible to the user instead of being stripped.

Reproduction

1. Create a cron job with delivery.mode = "announce" and channel = "imessage"
2. Cron generates output that gets passed as synthesizedText → roundOneReply → reply → findings
3. The agent's response includes reply threading metadata
4. buildCompletionDeliveryMessage() receives findings with tags still present
5. Tags are delivered to iMessage without being stripped

Suggested Fix

Call parseReplyDirectives() on params.findings before using it:

function buildCompletionDeliveryMessage(params) {
  const parsed = parseReplyDirectives(params.findings, { stripReplyTags: true });
  const findingsText = parsed.text.trim();
  // ... rest of function
}

This would align with other delivery paths that already strip tags correctly.

Workaround Attempted

Tried wrapping the imsg CLI to filter stdout, but ANY filtering breaks the bidirectional JSON-RPC protocol between OpenClaw and imsg, causing the iMessage provider to restart constantly.

Impact

• Tags are cosmetically ugly but don't break functionality
• Users see internal OpenClaw metadata in their messages
• Affects all announcement deliveries to iMessage (possibly other channels too)

Additional Context

The parseReplyDirectives() function exists and is used correctly in other parts of the codebase (e.g., line 32640 in the same file). The announcement delivery flow just needs to call it before building the completion message.