fix(gateway): honor group_allow_from for Telegram group/forum chats

[busminer]

What

_is_user_authorized_from_message in plugins/platforms/telegram/adapter.py short-circuited on adapter-level allow_from for every chat type. group_allow_from was never consulted at this intake gate, even though it's a documented config key.

Why

Practical effect discovered on a live deployment: an operator set allow_from (DM restricted to themselves) plus group_allow_from: ['*'] (groups open to everyone). Real group senders were silently dropped before mention-detection ever ran — no error, no log visible to the sender, just silence. Confirmed via a two-day-old CIS Telegram group where community members got zero replies while the operator's own DM continued working normally.

The downstream gateway/authz_mixin.py runner-level fallback check does union group_allow_from correctly — but it's unreachable once the adapter-level gate above it returns early.

Fix

Union group_allow_from into the allowed set for group/forum chat_type when it's configured, while preserving the existing allow_from-gates-everywhere behavior when group_allow_from is unset (this matches existing test expectations for backward compatibility — some deployments rely on a single allow_from restricting groups too).

How to test

tests/gateway/test_telegram_auth_check.py
tests/gateway/test_telegram_bot_auth_bypass.py
tests/gateway/test_telegram_callback_auth_fail_closed.py
tests/gateway/test_telegram_group_gating.py

All 80 tests pass locally (fresh venv, no other changes).

Platforms tested

Windows 10, Python 3.11, live Telegram gateway (not just unit tests) — the union behavior was verified end-to-end against a real group with a real non-operator sender getting through post-fix, and blocked pre-fix.

[alt-glitch]

This was generated by AI during triage.

Competing with #55496 (diff-verified canonical, allow_from-before-group-allowlist ordering rewrite) for the same Telegram group-allowlist intake gap. Also related: #55624 (messy variant already deduped into #55496) and #55529 (DM-half). This PR unions group_allow_from at the adapter intake gate; #55496 rewrites the ordering. Same goal, same file — maintainer picks. #55496 looks canonical (cleaner, diff-verified).

[busminer]

Closing in favor of #55496 — thanks @alt-glitch for the pointer, and I independently checked: #55496 (and its follow-up #55529 for the DM-side symmetry) is genuinely more complete than this PR. It handles the same intake-gate ordering bug, plus the allowed_users/group_allowed_users config-key aliases that people were actually trying to use but weren't bridged, plus group_allowed_chats as a chat-scoped fallback directly in the early gate rather than deferred.

Should have searched existing PRs/issues before opening this one per CONTRIBUTING.md — apologies for the duplicate noise. Root-caused and reproduced the bug independently on a live deployment before finding #55496, for what it's worth, so at least the report itself is corroborating evidence that #55462 is real and worth prioritizing.

🤖 Addressed by Claude Code