fix(qqbot): prevent Resume death-loop on Exception-disconnect path

[yunkai]

Problem

The except Exception branch in QQ Bot's _listen_loop handles WebSocket disconnects without a close code — typically triggered by QQ's TCP-layer idle timeout (~60s). This branch was missing three safety mechanisms present in the QQCloseError branch, causing the gateway to enter an infinite Resume death-loop: disconnect → Resume → disconnect every 60s, forever.

Pre-fix logs (April 29, 08:36–08:58)

WebSocket error → Reconnect → Resume sent (session_id=9aac..., seq=304)
WebSocket error → Reconnect → Resume sent (session_id=9aac..., seq=305)   # +60s
WebSocket error → Reconnect → Resume sent (session_id=9aac..., seq=306)   # +60s
...
Reconnect failed: Failed to get QQ Bot gateway URL   # rate-limited after ~22 min

Same session_id persists across all cycles, seq increments endlessly. QQ's TCP frontend does not reset its idle timer on WebSocket heartbeat frames, so Resume can never succeed without message traffic. Once rate-limited, the bot stays permanently offline — observed in production: 26+ hours of downtime.

Fix

Three mechanisms added to the except Exception branch:

1. Exception-disconnect window tracking + forced Identify: Count disconnects in a 300-second sliding window. After 5 disconnects with the same session_id, clear the session to force a fresh Identify on the next reconnect — breaking the death-loop.

2. Quick-disconnect detection: Mirror existing logic from the QQCloseError branch. Three disconnects within 5 seconds of connection triggers a fatal error with actionable guidance.

3. Backoff with upper bound: backoff_idx now increments on reconnect failures and is checked against MAX_RECONNECT_ATTEMPTS (100). Previously backoff_idx was reset to 0 on every successful reconnect, making it impossible to ever give up.

Related: #15051

This PR builds on the direction of #15051 (adding quick-disconnect detection to the Exception path) and extends it with window counting + forced Identify + backoff cap — all three mechanisms together provide a complete defense against the death-loop.

Post-fix validation (April 30)

20:34  Identify → Ready (session_id=3ff5...)
21:04  WebSocket closed: code=4009 Session timed out
21:04  Session error (4009), clearing session for re-identify  ✅
21:04  Identify → Ready (session_id=3c5f...)                   ✅
21:34  Session timed out → clearing → Identify → Ready         ✅
22:04  Session timed out → clearing → Identify → Ready         ✅
22:34  Session timed out → clearing → Identify → Ready         ✅

• ✅ No Resume death-loop (pre-fix: seq 304→324 continuously)
• ✅ 4009 session timeout correctly triggers clearing → re-Identify
• ✅ Connections rotate normally every ~30 minutes, zero exceptions
• ✅ Fresh session_id on each Identify

[alt-glitch]

Related to #15051 (open PR fixing same exception-path disconnect loop) and #15490, #17703. This PR adds window counting + forced Identify + backoff cap on top of quick-disconnect detection.

[alt-glitch]

Related to #15051 (open PR fixing same exception-path disconnect loop) and #15490, #17703.

[teknium1]

Thanks for isolating the generic exception-path loop. Current main still resets reconnect state after every successful socket reopen (gateway/platforms/qqbot/adapter.py:651-655), so this remains worth salvaging.

Problems

• The added quick-disconnect increment at PR line 579 is undone by the unchanged success arm at PR lines 606-608. A reconnect-success-immediate-disconnect cycle therefore never reaches MAX_QUICK_DISCONNECT_COUNT.
• The advertised backoff cap has the same issue: PR line 607 resets backoff_idx, so the existing cap cannot bound a cycle with successful socket opens.
• The diff changes only the adapter; it adds no regression test. Current tests/gateway/test_qqbot.py:2220-2241 covers the closed-socket raise, not repeated generic failures after successful reconnects.
• Current main now requires _mark_transport_disconnected() for this path (gateway/platforms/qqbot/adapter.py:643; commit 8199ec380), so the older _mark_disconnected() context should not be carried forward.

Suggested changes

• Preserve a loop-detection counter until a connection survives the configured threshold, and test successful reconnect followed by immediate generic failure.
• Keep current transport/lifecycle separation while salvaging the recovery policy.

Automated hermes-sweeper review.

[teknium1]

This increment is reset by the unchanged successful-reconnect arm at lines 606-608. In the reported reconnect-success-immediate-close cycle, the counter therefore stays at 1 and never reaches MAX_QUICK_DISCONNECT_COUNT; retain it until a connection survives the threshold or reset it from a confirmed healthy-session event.