fix(gateway): prevent 100% CPU spin when QQBot WebSocket is closed

[win847]

When the QQ Bot WebSocket transitions to a closed state (msg.type == WSMsgType.CLOSED), _read_events() raises RuntimeError once, which is caught by the except Exception block. However, _reconnect() only sets self._ws.closed = True but does not set self._ws = None. On the next loop iteration, _read_events() checks 'if not self._ws' (False, since it is still set) and enters the inner while loop, whose condition 'not self._ws.closed' is immediately False. The function returns normally without raising, causing the outer loop to reset backoff_idx to 0 - resulting in a tight 100% CPU spin loop that never reconnects until the process is killed.

Fix: add a 'self._ws.closed' guard at the top of _read_events() so it raises RuntimeError consistently whenever the transport is unusable, forcing the caller's except Exception block to drive proper reconnection with backoff.

[alt-glitch]

Competing fix for #17703 (QQBot CPU spin on closed WebSocket). See also #27821, #20994, and #19414 which address the same root cause via different approaches.

[teknium1]

This has been implemented on current main by the merged QQBot reconnect fix.

Evidence from this automated hermes-sweeper review:

• gateway/platforms/qqbot/adapter.py:684 on current main now checks self._ws.closed at _read_events() entry and raises RuntimeError("WebSocket closed"), preventing the normal-return/backoff-reset busy loop.
• tests/gateway/test_qqbot.py:2201 adds regression coverage for closed-but-non-None and None WebSocket entry states.
• The implementing merge is 3eeca4613d618618093db416b564a2b9ef8dbe6a from fix(qqbot): stop 100% CPU spin when WebSocket is closed but not None (#31193, #31771) #40574, which explicitly fixes the same QQBot 100% CPU spin described here.

Thanks for the report and patch. The earlier maintainer note correctly identified this as one of several competing fixes for the same QQBot root cause; main now carries that fix.