test(telegram): pin the in-flight-recovery guard on the dispatch stall watchdog

Gate finding 2ab (test teeth): the `or self._recovery_in_flight()` guard in
_check_ingress_dispatch_stall was untested though load-bearing. Without it the
watchdog counts a stall while an unrelated recovery is in flight, hands it to
_schedule_polling_recovery (which ignores it because a recovery is running),
and the latched "already reported" counter then swallows the stall for good.

test_dispatch_progress_rearms_the_report now stalls under an in-flight
recovery future (no report), resolves it, and requires exactly one report
after the threshold. Dropping the guard turns it red (assert 1 == 0).

tests/gateway/test_telegram_ingress_delivery_gap.py

@@ -80,6 +80,11 @@ async def test_dispatch_progress_rearms_the_report(caplog):
     caplog.set_level(logging.WARNING)
     with patch.object(adapter, "_schedule_polling_recovery") as sched:
         _receive(adapter, 3)
+        recovery = asyncio.get_running_loop().create_future()  # unrelated recovery in flight
+        adapter._polling_error_task = recovery
+        _heartbeats(adapter, tg_adapter._INGRESS_DISPATCH_STALL_HEARTBEATS + 1)
+        assert sched.call_count == 0  # deferred: a report now would be swallowed by the in-flight guard
+        recovery.set_result(None)
         _heartbeats(adapter, 3)  # 270s: a slow-but-bounded (<=300s) sequential handler is not a wedge
         assert sched.call_count == 0
         _heartbeats(adapter, 2)