fix(telegram): use real forum topic id in unified create_thread

[buddhism5080]

Discord Discussion URL: https://discord.com/channels/1491129282771288286/1537276565849907241

Summary

EN: Fix unified-mode Telegram forum topics: after auto-creating a topic from the main chat, agent replies no longer go to a non-existent message_thread_id (previously the trigger message id was misused as the topic id). Also demux GatewayResponse on the unified event bridge so create_topic responses are not mis-parsed as GatewayEvent (which produced invalid type: null, expected a string).

中文： 修复 unified 模式下 Telegram 超群自动建 topic 后无发失败：此前 create_thread 把触发消息的 message_id 当成 forum topic id 回传，导致 Bad Request: message thread not found（topic 其实已建好）。同时在 unified 事件桥上先分发 GatewayResponse，避免把 createForumTopic 的响应误当 GatewayEvent 解析报 null。

Context

Production log (unified binary, Telegram forum supergroup):

1. creating forum topic → forum topic created thread_id=Some("8")
2. unified bridge: event processing failed error=invalid gateway event JSON: invalid type: null, expected a string
3. agent runs successfully
4. gateway → telegram ... thread_id=Some("7") then telegram send failed: Bad Request: message thread not found

Root cause in UnifiedGatewayAdapter::create_thread: fire-and-forget create_topic, then thread_id: Some(trigger_msg.message_id) — wrong id type for Telegram forums. Standalone WS GatewayAdapter::create_thread already waited on GatewayResponse; unified did not.

No existing open PR found for this fix (searched create_thread / forum topic / message thread not found).

Fix

• AppState.pending_commands: oneshot map for in-process command responses
• UnifiedGatewayAdapter::create_thread: register waiter, set request_id, await real thread_id (5s timeout, same as WS path)
• try_complete_pending + main unified bridge: complete waiters before process_gateway_event
• CI workflow build-unified-binary.yml: build --features unified arm64/x64 artifacts (no local compile required)

Review Contract

Goal

Unified Telegram deployments must reply into the forum topic that was just created from a main-chat message, using Telegram's real message_thread_id.

Non-goals

• Changing Discord/Slack thread creation
• Redesigning the gateway event/response schema
• Adding a Telegram require_mention config knob
• Full e2e Telegram Bot API integration tests in CI (no live bot token)

Accepted Residual Risks

• On create_topic timeout/failure, behavior still falls back to parent channel (same as WS adapter) — replies may land in General instead of a topic.
• Orphan GatewayResponse with no waiter is dropped after demux (harmless; no longer spams invalid-event warnings).

Acceptance Criteria

• cargo clippy --workspace --features unified -- -D warnings and cargo test --workspace / unified build succeed in CI
• Code review: unified create_thread uses resp.thread_id from GatewayResponse, not trigger message id
• Manual (optional): General message in Topics-enabled supergroup creates topic and bot reply appears in that topic without message thread not found

Follow-ups

• Unit/integration test with a mock event_tx completing create_topic response
• Consider shared helper between WS GatewayAdapter::create_thread and unified path to avoid future drift

Test Plan

• Code path aligned with working standalone GatewayAdapter::create_thread
• CI: clippy/test/build with --features unified
• CI artifact: arm64 unified binary for local install
• Manual: restart local unified bot; General message → topic + visible reply

How to Verify

1. Review src/unified_adapter.rs create_thread + try_complete_pending
2. Review src/main.rs bridge demux order
3. Optional live: Topics supergroup, Manage Topics on bot, message in General without relying on wrong thread id

Risk Assessment

Medium — touches unified event bridge and create_thread only; WS gateway path unchanged. Residual: timeout fallback still posts to parent chat.

[github-actions]

Caution

This PR has been waiting on the author for more than 2 days (labeled pending-contributor since 2026-08-13).
It will be automatically closed in 24 hours if there is no update.

@buddhism5080 — You must add a new comment on this PR to remove the closing-soon label and keep it open. Pushing commits alone is not sufficient. Feel free to reopen a new PR later if it gets closed and you want to pick it back up.

[github-actions]

🔒 Auto-closing: this PR has had the closing-soon label for more than 1 days without activity from the author.

If you'd like to continue working on this, please submit a new PR and link to this one if necessary.