Bug

When a cron job with announce delivery fires and injects its result into a Telegram DM conversation, replying to that announced message binds the user's chat to the cron session instead of the main session. All subsequent DMs then route to the cron session.

Steps to Reproduce

1. Set up a cron job with delivery: announce and sessionTarget: isolated
2. Cron fires, result is announced into the user's Telegram DM
3. User replies to the announced message
4. All subsequent DMs from that user route to the cron's isolated session instead of agent:main:main

Expected Behavior

Replies to announced cron results should route to the main session, not the cron's isolated session. The announce delivery is just a relay — it shouldn't transfer session ownership.

Actual Behavior

• The in-memory chat-to-session binding switches to the cron session
• The binding persists across gateway SIGKILL + KeepAlive restart
• sessions_send to agent:main:main also routes to the cron session
• Only a full clean process restart (kill + fresh start) clears the binding
• sessions.json shows no explicit chat binding — it's purely in-memory

Impact

• User is stuck talking to a cron session with minimal context instead of their main session
• Main session (6.1MB of conversation history) becomes orphaned
• Recovery required manual gateway restart and 10+ minutes of downtime
• Agent operating in cron session doesn't realize it's not the main session (compaction summary in context made it look normal)

Environment

• OpenClaw 2026.2.22-2 (45febec)
• Telegram channel
• Cron job: morning-gratitude (isolated agentTurn, announce delivery)

Suggested Fix

Announced messages should be tagged as relay-only so replies route back to the originating session (agent:main:main), not the cron session that produced the content.