fix(qqbot): accept is_reconnect kwarg in connect() to match base class contract

[liuhao1024]

What does this PR do?

Adds the missing is_reconnect keyword argument to QQAdapter.connect() so it matches the base class PlatformAdapter.connect() contract. Without this, the gateway's reconnection logic passes is_reconnect=True and QQBot raises TypeError: connect() got an unexpected keyword argument 'is_reconnect', entering an infinite backoff loop.

Related Issue

Fixes #57252

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• gateway/platforms/qqbot/adapter.py — Changed async def connect(self) -> bool: to async def connect(self, *, is_reconnect: bool = False) -> bool: to match the abstract method signature in gateway/platforms/base.py:2864 and every other platform adapter.

How to Test

1. Configure QQBot with valid QQ_APP_ID / QQ_CLIENT_SECRET
2. Start the gateway — QQBot should connect successfully
3. Simulate a disconnect (e.g. network interruption) — the gateway should attempt reconnection without raising TypeError
4. pytest tests/gateway/test_qqbot.py -q should pass

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/gateway/test_qqbot.py -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A

[alt-glitch]

This was generated by AI during triage.

Duplicate of #52966 — the earliest still-open canonical fix for the same QQBot connect(is_reconnect=…) contract gap (issue #52914; this PR references #57252, an open re-report of the same bug). The prior cluster anchor #52922 is now closed/unmerged, so the canonical shifts to the earliest open PR #52966. Saturated cluster: #53540/#53546/#53948/#54029/#54037/#55494/#56970 are all the same one-line signature fix. Related: #52914, #57252.

[liuhao1024]

Superseded by #52966 which covers the same connect(is_reconnect=…) signature fix with tests and a more detailed docstring. Closing in favor of the earlier PR.