fix(telegram): clear_menus iterates global allowed_users causing USER_ID_INVALID on every group

[adolfousier]

Bug

In line ~1761, the / owner command registration loop chains global allowed_users into every group scope:

for uid in group.allowed_users.iter().chain(tg.allowed_users.iter()) {

This causes Telegram API USER_ID_INVALID errors on every group because the 4 global user IDs (8593093985, 686176803, 8365623776, 1611418118) are not members of most groups. The BotCommandScope::ChatMember call fails when the user isn't in the group.

Evidence

Same 4 errors on 9+ different groups in today's logs:

[ERROR] [agent] Failed to clear menu for user 8593093985 in group -1004332716514: USER_ID_INVALID
[ERROR] [agent] Failed to clear menu for user 686176803 in group -1004332716514: USER_ID_INVALID
[ERROR] [agent] Failed to clear menu for user 8365623776 in group -1004332716514: USER_ID_INVALID
[ERROR] [agent] Failed to clear menu for user 1611418118 in group -1004332716514: USER_ID_INVALID

Repeated for groups: -5483018934, -5509708814, -1003627148483, -1004406622817, -1004376662325, -5008492520, -1004446165687, -1004407925328.

Fix

Remove .chain(tg.allowed_users.iter()). Only clear menus for the group's own allowed_users. Global users who are in a group will already be in that group's allowed_users.

// Before
for uid in group.allowed_users.iter().chain(tg.allowed_users.iter()) {

// After
for uid in group.allowed_users.iter() {

Impact

• 4 USER_ID_INVALID errors per group on every owner command registration
• Noise in logs masking real errors
• No functional breakage (menu clearing still works for actual group members)

[adolfousier]

Fixed in 861b9ade, but not the way the issue proposed.

The suggested fix was to drop .chain(tg.allowed_users.iter()). That would have regressed the admins the loop exists for. types.rs:451 documents the tier, and user_allowed implements it:

if self.is_admin_or_owner(uid) {
    return true;   // short-circuits before the group lookup
}

Global allowed_users are allowed in every group, not only the ones listing them. Dropping the chain would leave a global admin who genuinely is a member with the default menu offering /start in that group, which is precisely what the loop clears.

The issue's own "Impact" section had it right: the errors are noise, not breakage. So the fix targets the noise.

What changed

• USER_ID_INVALID / PARTICIPANT_ID_INVALID / USER_NOT_PARTICIPANT are classified as "not a member here" and logged at debug. Everything else still warns.
• Admins appearing on both the global list and the group's own roster are deduped; they were being called twice per group.

Why not validate membership first

getChatMember fails the same way for a user the bot has never seen in that chat, so a pre-check costs an extra round trip per user per group and still errors. There is no roster to consult either: the config records a global grant, not membership. The failed call is the membership test.

Classification lives in src/channels/telegram/menu_scope.rs with tests in src/tests/telegram_menu_scope_test.rs, including one asserting real failures (CHAT_NOT_FOUND, BOT_WAS_KICKED, rate limits) still warn, so the change cannot go on to hide anything worth seeing.

cargo clippy --all-features --lib --bins --tests -- -D warnings clean, 5637 tests pass.