fix(qq): auto-detect active bot account

[sweetcornna]

Summary

Derive the active QQ Bot ID from the live OneBot event stream and present it as a runtime-managed, read-only value. Account switches stop retaining stale mention targets, while persisted self_ids remains a compatibility fallback and is never overwritten by unrelated UI saves.

Type

• feat: new user-facing behavior
• fix: bug fix or regression repair
• refactor: internal change with no intended behavior difference
• test: tests only
• perf: performance optimization
• docs: documentation only
• chore: tooling, dependencies, or maintenance
• ci: CI / workflow change

Scope / Packages Touched

• corlinman-channels: OneBot identity observation, current-event mention routing, health state
• corlinman-server/gateway: QQ status runtime identity projection
• ui: managed read-only Bot QQ ID and scan-login refresh
• release metadata: v1.36.1

Behavior Proof

• I added/updated automated tests, or explained why tests are not practical.
• I included real behavior proof when relevant: screenshot, video, logs, curl output, or before/after notes.
• proof: sufficient

Isolated running gateway + synthetic OneBot heartbeat, without sending a QQ message:

unauth=401 auth=200
{"account_online": true, "account_qq": 246813579, "health_online": true, "health_seconds_since_event": 29, "runtime": "connected", "self_ids": [246813579]}

The same status response retained persisted fallback truth independently:

{"config_keys":{"self_ids":["10001"]},"account_qq":246813579,"self_ids":[246813579]}

CI Gate

• py-ruff — uv run ruff check .
• py-mypy — all python/packages/*/src (621 source files)
• py-test — 7,286 passed, 7 skipped
• ui-typecheck — pnpm -C ui typecheck
• ui-lint — covered by successful Next production build (pre-existing warnings only)
• ui-test — full Vitest suite passed
• boundary-check — 2 contracts kept, 0 broken

Separate checks:

• proto-sync — N/A, no proto changes
• swift-mac — N/A

Module Boundaries / Proto

• No new reverse imports across the Python layering contract.
• No proto files touched.

Risk & Rollback

Risk: external OneBot clients with malformed or zero self_id continue using the persisted compatibility fallback. Valid per-event IDs are authoritative and account-offline state clears stale runtime identity.

Rollback plan: revert commit 2c8781b3; persisted QQ configuration is not migrated or deleted.

Ownership

Single-owner repository; no cross-team reviewer required.

Codex Review

Claude self-review is the repository's current review gate; no Codex wait is required.

Linked Issues

None.

Checklist

• PR title follows Conventional Commits.
• Tests added/updated; behavior proof supplied.
• No external reviewer required for this owner area.
• No --no-verify or hook-skipping used.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2c8781b3b3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Reset stale offline state when observing a new login

After a QQ account has been marked offline, this callback is the first code that runs when the re-login starts producing OneBot events again, but it only writes account_qq and leaves QQ_HEALTH["account_online"] as False. The status route's new effective_self_ids gate ignores detected ids while that flag is false, so the scan-login close refresh can keep showing the offline banner and configured fallback ID until the periodic health watcher runs (default 60s) despite live events having resumed; update the account-online state, or pass the event/heartbeat status through, together with the observed id.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Republish the same QQ id after offline clears it

When the account is kicked offline, the health watcher clears QQ_HEALTH["account_qq"]; if the operator scans back into the same QQ account, subsequent events carry the same self_id, but this de-dupe returns before calling on_self_id. In that same-account re-login path the status route has no way to restore the managed Bot QQ ID, so it can stay empty or fall back to the legacy config even after account_online recovers; reset this notified marker when account state is cleared, or allow republishing after an offline/stale transition.

Useful? React with 👍 / 👎.