fix(telegram): grant write to restricted members in default-deny chats

A default-deny discussion group reports a present or freshly joined member as `restricted` (no send right), not `member`. The join filter required `member`, so the real case never matched and a registered user stayed muted. Grant any eligible in-chat member (member or restricted) that still lacks the send right, with a loop guard (skip when send is already allowed) so the bot's own grant does not re-fire. Revoking a now-ineligible user stays the chat-gate path's job, so this never fights a chat_muted/block.
2026-06-21 16:12:58 +02:00
parent a404513037
commit 380f82438c
3 changed files with 100 additions and 36 deletions
@@ -611,3 +611,13 @@ Then Stage 18.
    the sweeper window (unit + integration); gateway hub `ResolveChatEligibility` + the chat-gate command; bot
    `chat_member` grant + `ApplyChatGate` getChatMember-guard; promo `/start` localization + URL button; config
    parsing.
+  - **Post-contour-test fixes (same PR):** a live test surfaced gaps. (1) **Join detection** — a
+    default-deny discussion group reports a present member as `restricted`, not `member`, so the grant
+    trigger now fires for any eligible in-chat member (`member` or `restricted`) still lacking the send
+    right, with a loop guard (skip when send is already allowed, so the bot's own grant does not
+    re-fire); revoking a now-ineligible user stays the chat-gate path's job, so this never fights a
+    `chat_muted`/block. (2) **Join-before-register** — a user who joins before registering is covered by
+    no `chat_member` event, so `ProvisionTelegram` now reports first contact and the Telegram auth
+    handler emits `chat_access_changed` on it. (3) **Observability** — a startup self-check logs whether
+    the bot is an admin-with-restrict in the chat (it caught a misconfigured `TELEGRAM_CHAT_ID` set to a
+    channel id instead of the discussion-group id), plus per-event grant-path logging.