feat(telegram-bot): route notifications into a per-channel forum topic

[dugynoo]

Summary

Adds an opt-in /setforum command that turns the telegram-bot's linear DM
inbox into a forum-topic layout, one topic per Huly chunter channel.
Top-level posts inside a topic become new Huly chat messages, and replies
to specific notifications still thread through to Huly as before.

The new flow is fully backwards-compatible: users that never run
/setforum see the existing single-thread DM unchanged.

What changes

• /setforum (DM-only in this iteration) stores the user's Telegram id
  as forumChatId on their integration. Uses getMe().has_topics_enabled
  (Bot API 9.4) to refuse early if Threaded Mode is not enabled, instead
  of probing with createForumTopic + deleteForumTopic which leaves a
  service message in the chat.
• /unsetforum clears the routing and reverts to the legacy DM layout.
• processNotification calls resolveForumTopic whenever forumChatId
  is set on any of the user's integrations. The first notification for a
  Huly channel lazily creates a topic named #channel-name (or the DM
  peer's display name) via createForumTopic. The mapping is persisted
  in a new telegram_bot.forum_topics table.
• handleForumTopicMessage routes top-level Telegram posts inside a
  known topic to sendMessage on the matching ChunterSpace, so users
  can start fresh threads from Telegram. Reply-to-message inside a topic
  still flows through onReply for thread linking.
• Replies that target the topic's first system message (i.e. the user is
  "replying" to the synthetic topic head when they open it to type) are
  treated as fresh forum-routed posts instead of attempting to thread
  them back to a non-existent activity message.
• Telegram forum service messages (forum_topic_created/_edited/_closed/
  _reopened/general_forum_topic_hidden/_unhidden) are skipped at the top
  of bot.on(message()) because they carry a message_thread_id but should
  not trigger the workspace/channel keyboard fallback.

Testing

• git diff --check upstream/develop..HEAD
• Manually verified end-to-end on a self-hosted Huly deployment
  (v0.7.423): /setforum, notification to a channel produces a topic
  named #channel-name, top-level reply lands as a new ChatMessage,
  reply-to-notification threads via the existing onReply path.

Notes

• DM-only in this iteration. Routing into a forum supergroup with
  multiple users sharing one chat is a natural follow-up but requires a
  PK change on forum_topics for per-chat dedup and is intentionally
  deferred to a separate PR.
• Only chunter sources (Channel, DirectMessage) are routed. Other
  activity message kinds fall back to the legacy DM so unknown sources
  are not silently dropped.
• The new forum_topics table uses CREATE TABLE IF NOT EXISTS; no data
  migration is required to upgrade an existing deployment.

[huly-github-staging]

Connected to Huly®: UBERF-16483