fix(qqbot): accept is_reconnect kwarg in connect() to fix reconnect

[Bartok9]

Summary

• QQAdapter.connect() now accepts the keyword-only is_reconnect flag, matching the PlatformAdapter.connect() contract every other adapter already implements.
• Fixes QQ Bot failing to reconnect after any disconnect on v0.17.0.

Root Cause

Symptom — After v0.17.0, QQ Bot fails to reconnect after a disconnection; the log shows QQAdapter.connect() got an unexpected keyword argument 'is_reconnect'.

Root cause — gateway/run.py::_connect_adapter_with_timeout() always forwards adapter.connect(is_reconnect=is_reconnect) (added in #46621 so adapters can distinguish a cold boot from a watcher reconnect). Every platform adapter declares async def connect(self, *, is_reconnect: bool = False) — except gateway/platforms/qqbot/adapter.py, which still had the old signature async def connect(self). On the reconnect path (run.py line ~6855, is_reconnect=True) the keyword binding raises TypeError, so the reconnect attempt dies and QQ never comes back.

Evidence — grep "async def connect" gateway/platforms/*.py gateway/platforms/*/adapter.py shows qqbot is the lone outlier; run.py:3132/3135 always pass the kwarg. New test test_connect_callable_with_is_reconnect_kwarg reproduces the exact TypeError on the old signature.

Fix + why this level — Fix at the adapter signature (the source of the contract violation), not by wrapping the call site in try/except TypeError (the issue’s alternative). The base class already documents the flag; bringing qqbot into line is the correct, narrowest fix and avoids masking real TypeErrors at the call site. QQ keeps its own server-side resume state (_session_id/_last_seq) and has no separate update queue to preserve, so the flag is accepted and ignored per the base-class note that adapters without such a queue may ignore it.

Scope / risk — One-line signature change + docstring; behavior is unchanged for the existing cold-boot path (is_reconnect defaults to False). No other call sites touched.

Tests

Added TestQQConnectIsReconnectKwarg (2 cases) in tests/gateway/test_qqbot.py:

• test_connect_signature_accepts_is_reconnect — asserts the keyword-only param with False default.
• test_connect_callable_with_is_reconnect_kwarg — calls connect(is_reconnect=True) (forced early return via AIOHTTP_AVAILABLE=False), asserts no TypeError.

Real captured output:

Without the fix:

>           result = asyncio.run(adapter.connect(is_reconnect=True))
E           TypeError: QQAdapter.connect() got an unexpected keyword argument 'is_reconnect'
FAILED tests/gateway/test_qqbot.py::TestQQConnectIsReconnectKwarg::test_connect_signature_accepts_is_reconnect
FAILED tests/gateway/test_qqbot.py::TestQQConnectIsReconnectKwarg::test_connect_callable_with_is_reconnect_kwarg
2 failed, 161 deselected in 0.27s

With the fix (full qqbot suite):

163 passed, 4 warnings in 2.99s

(the 4 warnings are pre-existing coroutine-cleanup warnings unrelated to this change)

Fixes #54679

[alt-glitch]

This was generated by AI during triage.

Duplicate of #52966 — identical one-line fix (adding the keyword-only is_reconnect param to QQAdapter.connect()) for #52914. #52966 is the earliest still-open PR in a saturated cluster (#52922 was closed; #53540/#53546/#53948/#54029/#54037/#55419 are the same fix). Regression breaking QQBot reconnect on v0.17.0.

[Bartok9]

Thanks @alt-glitch — you're right, this is the same one-line fix as #52966, which is the earliest still-open PR in the cluster. Closing this in favor of #52966 to keep triage clean. 🙏