fix(telegram): use senderID and chatIDStr for message handling

[blib]

📝 Description

handleMessage constructed a compound senderID ("<id>|<username>") for the allowlist check but then passed only the numeric fmt.Sprintf("%d", user.ID) to HandleMessage. This meant downstream consumers (session key, metadata, logs) never saw the username component, and—more importantly—the senderID stored in the inbound message wouldn't match allowlist entries that use the @username form.

The same issue applied to chatID: a separate chatIDStr was already computed earlier in the function but HandleMessage was called with a redundant fmt.Sprintf("%d", chatID).

This PR reuses the already-computed senderID and chatIDStr variables, fixing the mismatch and removing the duplicate formatting.

🗣️ Type of Change

• 🐞 Bug fix (non-breaking change which fixes an issue)

🤖 AI Code Generation

• 👨‍💻 Mostly Human-written (Human lead, AI assisted or none)

🔗 Linked Issue

#310

📚 Technical Context (Skip for Docs)

• Reasoning: senderID was built as fmt.Sprintf("%d|%s", user.ID, user.Username) on L204 but HandleMessage on L358 was called with fmt.Sprintf("%d", user.ID), discarding the username part. The fix is a one-line change reusing the existing locals.

[Copilot]

Pull request overview

This PR fixes a bug in the Telegram channel's message handling where the sender and chat identifiers passed to HandleMessage didn't match the format used for allowlist checks. The code was constructing a compound senderID (including username) and chatIDStr for validation but then discarding them and recreating simpler numeric-only versions when calling HandleMessage, causing allowlist mismatches.

Changes:

• Reuses existing senderID and chatIDStr variables in HandleMessage call instead of reformatting numeric IDs

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.