Strip <relevant-memories> blocks from outbound channel messages (Telegram, Discord, etc.)

Description

When the memory plugin (openclaw-mem0 or memory-lancedb) injects <relevant-memories> context via the prependContext hook, and the LLM echoes/reflects this block in its response, the raw <relevant-memories>...</relevant-memories> markup is delivered verbatim to messaging channels like Telegram. This leaks internal memory context to the user as visible plaintext.

The Web UI already has a fix for this (#29851) that strips <relevant-memories> scaffolding from rendered assistant messages. However, the same sanitization is not applied to outbound messages sent through messaging channels (Telegram, Discord, Slack, iMessage, etc.).

Steps to Reproduce

1. Configure openclaw-mem0 (or any memory plugin that uses prependContext) with autoRecall enabled
2. Connect a Telegram channel
3. Send messages that trigger memory recall (the plugin injects <relevant-memories> blocks into the user prompt)
4. Wait for the LLM to reflect/echo the <relevant-memories> block in its response (happens intermittently, more common with longer context or subagent completions)
5. Observe the raw <relevant-memories> block rendered as visible text in Telegram

Expected Behavior

The <relevant-memories> block should be stripped from assistant responses before delivery to any channel, just as it is in the Web UI. The user should never see internal memory scaffolding.

Actual Behavior

The <relevant-memories>...</relevant-memories> block (including the preamble text like "The following are stored memories for user...") is rendered as visible plaintext in Telegram messages.

Example of what Kevin sees in Telegram:

<relevant-memories>
The following are stored memories for user "kevin". Use them to personalize your response:
- Kevin prefers operator mode with verification discipline
- VEDA uses Opus 4.6 as main model
...
</relevant-memories>

[Actual response follows]

Environment

• OpenClaw version: 2026.4.26
• Memory plugin: @mem0/openclaw-mem0 1.0.4
• Channels affected: Telegram (long-polling), likely all messaging channels
• Web UI: Not affected (already has fix from #29851)

Analysis

How prependContext works

The memory plugin returns <relevant-memories> blocks via the beforeAgentStart / before_prompt_build hook's prependContext field. The gateway prepends this directly to the user message text:

// agent-harness-runtime-CpgGKKoD.js:49
prompt: joinPresentTextSegments([promptBuildResult?.prependContext, legacyResult?.prependContext, params.prompt])

// prepare.runtime-O4dLDhbV.js:765
if (hookResult.prependContext) preparedPrompt = `${hookResult.prependContext}\n\n${preparedPrompt}`;

Where sanitization happens (and doesn't)

• ✅ Web UI: Strips <relevant-memories> from rendered chat messages (#29851)
• ✅ Memory capture pipeline: Strips <relevant-memories> before sending to Mem0 extraction (mem0 plugin line ~3988)
• ✅ iMessage inbound: detectReflectedContent() catches relevant-memories-tag pattern and drops reflected inbound messages
• ❌ Channel outbound: No stripping. The parseChunk → splitMediaFromOutput → emitBlockReply pipeline has no filter for <relevant-memories> tags

Related mechanisms that DON'T cover this

• stripInternalRuntimeContext handles <<<BEGIN_OPENCLAW_INTERNAL_CONTEXT>>> blocks but not <relevant-memories>
• detectReflectedContent in monitor-ChxbhW0l.js detects the pattern but is only used for iMessage inbound filtering

Suggested Fix

Add <relevant-memories> stripping to the channel outbound text processing pipeline, before text reaches emitBlockReply. The regex is already proven in the mem0 capture pipeline:

text = text.replace(/<relevant-memories>[\s\S]*?<\/relevant-memories>\s*/g, "").trim();

Ideal locations:

1. In parseChunk (selection-D9uTvvsw.js) after splitMediaFromOutput — affects all channels
2. Or extend stripInternalRuntimeContext to also handle <relevant-memories> blocks
3. Or add a general plugin-context sanitizer for outbound messages

This should preserve <relevant-memories> inside code fences (matching the Web UI behavior from #29851).