fix(telegram): emit chat_type metadata for group-safe prompt behavior

[rozgo]

Summary

• emit metadata.chat_type for inbound Telegram messages using Telegram's source chat type
• keep TelegramMessageMetadata backward-compatible by making chat_type optional on deserialize
• add Telegram regression coverage for legacy metadata parsing and group message emission

Linked Issue

Fixes #2482

Change Type

• Bug fix

Review Track

• B

Validation

• cargo fmt --all -- --check
• cargo clippy --all --benches --tests --examples --all-features -- -D warnings
• cargo build
• cargo test test_telegram_message_metadata_deserializes_without_chat_type (in channels-src/telegram)
• cargo test --features integration --test telegram_auth_integration test_group_message_emits_chat_type_metadata -- --nocapture
• cargo test

cargo test currently fails in an unrelated upstream e2e assertion:

tests::tool_info_clarifies_message_and_channel_setup_roles in tests/e2e_builtin_tool_coverage.rs

This failure is outside the Telegram diff.

Impact

• Security Impact: none
• Database Impact: none
• Blast Radius: Telegram metadata emission and downstream group/private prompt detection
• Rollback Plan: revert this commit

[gemini-code-assist]

Code Review

This pull request introduces a chat_type field to the TelegramMessageMetadata struct to facilitate downstream detection of group and private chats. The changes include updating the message handling logic to populate this field, adding a unit test for backward compatibility during deserialization, and adding an integration test to verify metadata emission. A review comment suggests improving type safety by using a dedicated enum for the chat_type field instead of a raw String.

[gemini-code-assist]

For better type safety and to make the code more robust, consider using an enum for chat_type instead of a String. The possible values are well-defined (private, group, supergroup, channel).

Using an enum aligns with the 'Parse, Don't Validate' principle, ensuring type safety at the boundary where this data is processed. This would make downstream logic that consumes this metadata less prone to errors from string comparisons.

You could define an enum like this:
#[derive(Debug, Serialize, Deserialize, Clone, PartialEq, Eq)]
#[serde(rename_all = "lowercase")]
pub enum TelegramChatType {
Private,
Group,
Supergroup,
Channel,
}

Then, you would change this field's type to Option<TelegramChatType>. This would also require updating handle_message to parse the string from message.chat.chat_type into this new enum.

References

1. For inputs that require validation (like timezone strings), prefer creating a newtype wrapper that validates on construction. This 'Parse, Don't Validate' approach ensures type safety and centralizes validation at system boundaries.

[henrypark133]

Review: Telegram metadata fix looks correct

I verified the chat_type emission path and the added compatibility coverage. I did not find a blocker in the changed code.

Positives:

• Inbound Telegram messages now persist the source chat type in metadata without changing the existing is_private behavior.
• Deserialization stays backward-compatible because chat_type is optional on read.
• The integration test hits the real webhook path and asserts the emitted metadata, which is the right caller-level coverage for this fix.

Residual risk:

• This is based on code inspection plus the targeted tests in the diff; I did not run the Telegram integration suite from this review pass.

[rozgo]

Rebased this branch onto current staging and force-pushed with --force-with-lease to pick up upstream CI fixes; no functional changes to the Telegram patch. Local revalidation on the rebased branch: cargo fmt, cargo clippy, cargo build, the Telegram metadata compatibility unit test, and the Telegram group-message integration test all pass. Full cargo test currently fails in an unrelated upstream assertion in tests/e2e_builtin_tool_coverage.rs.