[1/2] feat(eve)!: key Telegram group sessions chat-wide

[Lukavyi]

Summary

A Telegram bot in a group has no memory between mentions. Group and supergroup inbound messages key the session to the bot message being replied to, or to the mention itself when it is not a reply (conversationIdForMessage in telegram/state.ts), and outbound group sends re-key the session to the posted message id. Every fresh @bot mention therefore starts a new session with one message of context, while private chats already keep one continuous session per chat since #377.

This makes groups behave like private chats: one session per chat, or per forum topic, keyed to telegram:<chatId>:<messageThreadId>:. Mentions, replies to bot messages, HITL callback queries, and outbound sends all resume that session, so the bot remembers what it said earlier in the chat.

• Non-forum supergroups stamp message_thread_id on replies (the reply-chain root, not a topic). The thread id now counts as a session discriminator only when Telegram marks the message with is_topic_message, so a reply chain does not fragment the chat-wide session. isTopicMessage is exposed on TelegramMessage and TelegramMessageReference for this.

• The per-bot-message anchoring is removed rather than kept behind an option, following the reasoning in Telegram: group mentions start a new session per bot message; key groups chat-wide like private chats #874: it is reproducible in userland (conversationId on a proactive receive target still pins a thread, and Let the host pick the session for an inbound turn (continuation token override) #671 would cover inbound), while the reverse was not possible without patching channel internals. A late reply to an old bot message also resumed a session blind to everything since, so the anchoring was not correct even for the multi-thread case it served.

• Second commit: a reply to a bot message is delivered with its text as message alongside the synthetic telegram_reply:<id> response again. The initial channel did this; feat(eve)!: unify public session operation APIs #1597 switched the reply path to respond() with only the response, so a reply that was not an answer to a pending ForceReply prompt resolved to nothing in the adapter and the session re-parked without a turn. With chat-wide sessions a reply to the bot is the ordinary follow-up, so this matters more than before. The adapter already had the fallback and the test for it.

Behavior change for existing group bots, hence the minor changeset and the ! in the commit. Existing parked group sessions keep their old anchored tokens; new mentions start on the chat-wide token.

We have run chat-wide group keying as a patchedDependencies patch in production on two group bots since July.

Related to #874 (option 1 there). #671 is the more general mechanism; this is the smaller change that fixes the group use case now.

How this lines up with the other channels

Channel	Session key	Boundary
Slack	channel:threadTs	a thread, visible to the user
Teams	tenant:conversation:rootActivityId	a thread, visible to the user
Discord	channel:interactionId	one slash command; the channel has no inbound messages
Telegram (before)	chat:topic:botMessageId	a reply chain to one bot message; not visible to the user
Telegram (after)	chat:topic:	the chat or forum topic, visible to the user

Slack and Teams key a session to the smallest container the platform itself shows: a thread. Telegram has no threads outside forum topics, and instead of taking the nearest visible container (chat or topic) the channel synthesized its own boundary from the reply chain to a bot message. Users cannot see that boundary, which is why a plain @bot mention that is not a reply reads as "the same conversation" to them and as "a new session" to eve. Teams had the same class of bug in #211 (a follow-up mention in a thread lost context) and it was fixed as a bug, not made an option.

The Telegram and Discord channels share one shape from the initial commit (conversationId state, anchor() after outbound posts, the same conversationId/initialMessage guard). Discord is interaction-only, so "one session per bot post" is the natural unit there. Telegram inherited that unit for groups; private chats were exempted from the start, and #377 later kept the group anchoring as-is while fixing proactive private chats. After this change Telegram behaves like Slack and Teams, and Discord stays the justified exception.

Validation

pnpm --filter eve exec vitest run --config vitest.unit.config.ts src/public/channels/telegram   # 63 passed
pnpm --filter eve exec tsc -p tsconfig.json --noEmit
pnpm run docs:check
pnpm run guard:invariants

New coverage: a fresh mention, a reply to a bot message (freeform HITL path), a mention inside a forum topic (is_topic_message: true keeps the topic), a reply-chain message_thread_id in a non-forum supergroup (stays chat-wide), a HITL callback query, and an outbound post that must not re-key the session. The existing anchoring tests were rewritten to assert chat-wide tokens; the one that asserted re-keying to the posted message id was dropped, and the explicit-conversationId group test now asserts the id is preserved instead of overwritten.

Checklist

• This change was requested or approved by a maintainer (asked in Telegram: group mentions start a new session per bot message; key groups chat-wide like private chats #874, awaiting an answer)
• I ran the relevant checks from CONTRIBUTING.md
• I added tests and documentation where relevant
• I added a changeset if this touches the published eve package
• DCO sign-off passes for every commit (git commit --signoff)

🤖 Generated with Claude Code

https://claude.ai/code/session_015P6RBuagWTMzBmJLCiYKW9

[vercel]

@Lukavyi is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[Lukavyi]

Pushed 304b1ea: a reply to a bot message now carries its text as message on the same delivery as the synthetic telegram_reply:<id> response. The adapter still resolves a pending freeform answer first; when no prompt is registered, the text runs as a normal turn instead of the session re-parking without a turn. Also corrected the TelegramReceiveTarget docstring (conversationId pins an id that inbound never routes to; initialMessage stays chat-wide in groups). Telegram unit suite: 62 passed; tsc, guard:invariants, docs:check clean.

[Lukavyi]

Ready for review. @benpankow (recent Telegram HITL work) @ruiconti (merged #897, which this relies on): could one of you take a look? #3023 stacks on top with the observe half.