Description

Setting replyToMode to "first" or "all" in the config has no effect. The bot sends replies as standalone messages instead of threading them as replies to the user's message. This affects all channels that support reply threading (Telegram, Discord, Slack, etc.).

Root Cause

replyToMode is implemented as a filter (in createReplyToModeFilterForChannel), not a generator. It strips or keeps replyToId on payloads, but replyToId is only ever populated when replyToCurrent is set on the payload — which only happens if the LLM emits a [[reply_to_current]] tag in its response text.

Since LLMs almost never emit [[reply_to_current]] unprompted, replyToId is never set, and the replyToMode filter has nothing to act on. The result: replyToMode: "first" and replyToMode: "all" behave identically to "off".

Steps to Reproduce

1. Set replyToMode: "first" (or "all") in config
2. Send a message to the bot on Telegram (or any channel with reply support)
3. Bot replies as a standalone message — no reply arrow / no threading

Expected Behavior

With replyToMode: "first", the first reply payload should be threaded as a reply to the user's message. With "all", every reply payload should be threaded.

Suggested Fix

Auto-inject replyToCurrent: true on payloads before passing them to applyReplyTagsToPayload, in both code paths:

1. applyReplyThreading in src/auto-reply/reply/reply-payloads.ts (the final-reply path)
2. The block-streaming path in src/auto-reply/reply/agent-runner-execution.ts

This way replyToId is always populated with currentMessageId, and the existing replyToMode filter then correctly decides whether to keep or strip it based on the config setting.