fix(telegram): reject messages that @mention a different bot in group chats

[saheljalal]

What does this PR do?

When multiple Hermes bots share a Telegram group and require_mention: false, every bot responds to all messages — including messages where a user explicitly @mentions a different bot. This adds filtering to reject such messages before processing, achieving parity with the Discord adapter which already handles this correctly.

Root Cause

The Telegram _should_process_message() flow checked free_response_chats then require_mention — if false, it returned True immediately. There was no gate for messages that explicitly target another entity via @mention or text_mention entities (only /command@otherbot was handled).

Additionally, _message_mentions_bot() and the new filtering both needed to scan the same entities, causing duplicate iteration when called sequentially from _should_process_message().

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• gateway/platforms/telegram.py — Extract _iter_entity_sources() (static) and _resolve_entity_targets() (single-pass scanner returning (self_mentioned, other_mentioned, other_command)). Refactor _message_mentions_bot() to delegate to the shared scanner. Add _message_targets_other_bot() that also delegates, positioned in _should_process_message() after free_response_chats but before require_mention.
• tests/gateway/test_telegram_group_gating.py — 11 new tests covering: @Otherbot rejected (require_mention false/true), @self not rejected, @self+@other dual mention not rejected, general messages unchanged, @human_user rejected, /command@otherbot rejected, @Otherbot in caption entities, text_mention of other user rejected, text_mention of self not rejected.

Behavior

Message	require_mention: false	require_mention: true
hello everyone	✅ accepted	❌ rejected (no mention)
@hermes_bot help	✅ accepted	✅ accepted
@otherbot help	❌ rejected (new)	❌ rejected
@hermes_bot @otherbot help	✅ accepted (self mentioned)	✅ accepted
@john_doe hello	❌ rejected (new)	❌ rejected
/status@other_bot	❌ rejected (new)	❌ rejected

Discord Parity

Mirrors the multi-agent filtering in discord.py (~L710-730). Telegram does not provide m.bot for mention entities, so we use entity text comparison instead.

How to Test

1. pytest tests/gateway/test_telegram_group_gating.py -v — all 25 tests pass (14 existing + 11 new)
2. Manual: deploy two Hermes bots to a shared group with require_mention: false. @mention one bot and verify only that bot responds.

Checklist

Code

• I have read the Contributing Guide
• My commit messages follow Conventional Commits (fix(gateway): ...)
• I searched for existing PRs to make sure this is not a duplicate
• My PR contains only changes related to this fix (no unrelated commits)
• I have run pytest tests/ -q and all tests pass
• I have added tests for my changes
• I have tested on my platform: Ubuntu (Linux)

Documentation and Housekeeping

• Updated relevant docstrings — N/A for README/docs
• Updated cli-config.yaml.example — N/A (no new config keys)
• Updated CONTRIBUTING.md/AGENTS.md — N/A (no architecture change)
• Cross-platform impact — N/A (Telegram gateway, no OS interaction)
• Updated tool descriptions/schemas — N/A (no tool changes)

Related Issue

Fixes #20373

[teknium1]

Automated hermes-sweeper review: this Telegram multi-bot routing fix is already implemented on current main.

Evidence:

• gateway/platforms/telegram.py:5251 now rejects messages where explicit bot mentions exclude this adapter before the free_response_chats and require_mention gates.
• gateway/platforms/telegram.py:4820 extracts explicit bot usernames from text/caption entities, including /command@botname disambiguation.
• tests/gateway/test_telegram_group_gating.py:498 covers require_mention: false with @Interntestnumber1bot: the non-target bot ignores it and the mentioned bot processes it.
• tests/gateway/test_telegram_group_gating.py:508 covers /stop@Interntestnumber1bot exclusivity when mentions are not required.
• The relevant implementation landed across ce4d8570215a7e601e13de5936853b64c355ef5d and follow-up fbfe2948827b8bdd6e0c0f1aa71eb897938f9635.

Thanks for the original report and fix direction; the same bug class is now handled on main.