Function run_poll_loop 

pub async fn run_poll_loop(
    config: TelegramConfig,
    http: Client,
    outbound_rx: UnboundedReceiver<OutboundMsg>,
    health: Arc<Mutex<BridgeHealth>>,
)

Runs the inbound long-poll loop and the outbound send loop as two fully independent tasks (tokio::join!, not tokio::select! on a shared loop iteration).

The original design interleaved both in one tokio::select!: whichever branch was constructed fresh each iteration. That meant an outbound send arriving mid-poll would drop (cancel) the in-flight getUpdates future, and — worse — any rate-limit backoff sleep inside outbound handling (up to a Telegram-specified retry_after, potentially many seconds) blocked the entire loop, including inbound polling, since both branches shared one iteration. A burst of outbound sends (e.g. edit_message_id streaming updates) could starve inbound message delivery for as long as the burst + backoff lasted. Splitting into two independently-scheduled tasks removes this coupling entirely: the inbound poll always runs on its own cadence regardless of outbound activity.